Hrrmmm shouldn't those lines be...
rirving at onecall.net
Thu Sep 7 22:07:10 UTC 2000
Heath Kehoe wrote:
> >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?
Placing an ampersand in front of an array, even
if it is an element of the structure.....
> > 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?
What does the (Just Kidding) have to do with it,
would be a corrected question.
I'll leave that as a exercise for the reader.
> >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.
Hrrm. I think this logic may not lint clean...
Now, I can memcpy ( array, target, size), or, I can memcpy (
&array, target, size ).
According to my tired old K&R background, number 2 is wrong..
err...sloppy, in C.
If you want to use the second, in the manner you suggest, I might
memcpy ( &array, target, size ). Which is great if the array
-isn't- an array
just my .02
New compilers protect us from too much.
More information about the inn-workers