Hrrmmm shouldn't those lines be...
heath.kehoe at intermec.com
Thu Sep 7 21:55:01 UTC 2000
>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.
More information about the inn-workers