[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Clean code to be 64bit clean

From: Jay 'Whip' Grizzard <elfchief_at_lupine.org>
Date: 2003-11-30 23:32:03 CET

> > Moreover, in general long is only
> > type that is supposed (in practice) to hold void *, but this is not
> > required by standard, so you should not count on it everywhere.
> It's a bit off-topic, but the ISO C 99 stdint.h header optionally
> provides intptr_t and uintptr_t. When these types are provided it is
> guaranteed that a void* can be cast to a [u]intptr_t and then cast
> back to the original void* value.

I'm not familiar with the C99 spec (someone feel free to buy me a copy! ;),
but from the names of the types, intptr_t (etc) seem to be integer pointers.

The subversion code being talked about doesn't convert int pointers back
and forth from (void *) -- it converts (int) back and forth from (void *).

This is not, has not been, and never will be either legal, or a good
thing to do. There only requirement with (void *) is that any type of
pointer can be cast to (void *) and then back to its original type.
There's no guarantee that any other type can be cast to/from (void *)
without damage -- And, indeed, on some obscure platforms (admittedly, not
any that subversion supports, I don't think), there actually aren't any
integer datatypes capable of holding pointer datatypes without damage.

The right answer to this type of problem is almost always "write the code
correctly" -- which is to say, don't treat (void *) and ([long] int) as
interchangeable, because they aren't. Given the generally high quality
of the subversion code, I'm impressed that such poorly behaved code
could even get into the codebase...

Of course, I'm just a random pedant off in the wings somewhere... I'll be
happy to take my $0.02 and go home now... :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 30 23:32:54 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.