On Wed, Aug 4, 2010 at 4:12 PM, Julia Lawall <[email protected]> wrote:
> Actually, there is a problem in your example program. On line 10, there
> is:
>
> typedef char mytype;
>
> which should be:
>
> typedef char my_type;
Humn... bad file. I've updated the file. This one gives a false positive.
> With that change a.c doesn't give any reports. I have the impression that
> this is because it is taking the last definition of the typedef. But then
> I guess there is a problem of a false negative.
You are right. The var must have the same name, but with different
types depending on #ifdefs
> In the short term, I don't think Coccinelle is going to keep track of
> processing #ifdef branches consistently. Perhaps you want to just run cpp
> first? There is some support for this, but unfortunately I don't know
> what it is.
I'll try, but maybe I can just eliminate the false positives now that
I know what to look for.
thanks
Lucas De Marchi
#if USE_GNUTLS
typedef struct _my_type
{
int a;
int b;
} my_first_type;
static my_first_type *server_cert = NULL;
#elif USE_OPENSSL
typedef struct _my_type
{
long a;
long b;
} my_second_type;
static my_second_type *server_cert = NULL;
#endif
#if USE_GNUTLS
static int f()
{
server_cert = malloc(sizeof(my_first_type));
}
#endif
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
