Hrrmmm shouldn't those lines be...

[Heath Kehoe]

>
>Hrrmmm.. I am nit picky.
>
>They should devolve to the same thing,
>but, in some cases it can be "not defined".... .

I don't follow you... what is not defined?

>
>  So, you want to compile on 32 bit stuff forever  ?
>
>  (Just kidding)
>
>   I am actually looking for possible leaks...
>

What does "32 bit" have to do with this?  

>
>Same problem in, issue , BTW,
>
>trash.c - line 27:
><        memset(&token.token, '\0', STORAGE_TOKEN_LENGTH);
>>        memset(token.token, '\0', STORAGE_TOKEN_LENGTH);
>
>
>ov3.c - line 176:
><    memset(&CACHEdata, '\0', sizeof(CACHEdata));
>>    memset(CACHEdata, '\0', sizeof(CACHEdata));
>
>
>buffindexed.c - line 881: 
><  memset(&groupdatablock, '\0', sizeof(groupdatablock));
>>  memset(groupdatablock, '\0', sizeof(groupdatablock));
>

I think these should be left alone.  If nothing else, the '&' serves
as an indicator to someone looking at the code for what is going on.
When you see '&CACHEdata' you know you've got a pointer to a data
structure of some kind.  In this case, '&CACHEdata' is a pointer
to an array.  If you use 'CACHEdata' instead, you're getting a pointer
to the first element of that array.  It happens that those pointers
are for the same physical address; but they are semantically different.

-heath