Raphael Manfredi wrote:
> Quoting Christian Biere <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
> :Then what is the purpose of checking 'lid'? It seems pmi->nl can actually
> :be a dangling pointer and this is the point of the check. The code could
> :be made standard compliant by using pmi->lid instead of pmi->nl because
> :'lid' already maps to either 'nl' or NULL. Likewise, 'nl' could be carried
> :around as an integer instead of a pointer. Admittedly, a GarbageHashTable
> :defeats this by casting it back to a pointer - if you use that directly
> :as key - which you don't have to.
> 
> I perfectly know I'm handling a possibly dangling pointer value, and this
> is the purpose of the hash table.

Just a few mails ago you claimed there is no dangling pointer. I only
wrote the lengthy description because you refused to explain the purpose.

> I know I could have used an ID in the
> table, but as it is a running count it would have meant using a 64-bit
> ID and that would imply the use of 64-bit atoms, and I don't want that.

I never claimed you don't know what you're doing. Apparently you know
quite well that what you do is a hack and an unnecessary one at that.
 
> But let's face it: this code works fine as it is.

I don't know that.

> An implementation of a
> C compiler that would put a level of indirection to all pointer accesses
> just to prevent using a pointer that has been freed would be braindead.

It's not as braindead as exploits made possible by buffer overflows after
30 years and more of experience with C. Also you seem to think that your
idea of why this might be invalid is the only possibility. Don't you
think that someone coding for MS-DOS would consider it absurd that you
mustn't dereference NULL? Even on some Unix-like systems it might not
cause any crash or other problems. In fact, not long ago, many allowed
you to map memory at address 0x0.

> Otherwise, if one handles the actual pointer value not like a pointer but
> as any normal integer quantity, then it is perfectly safe.

Yes, once casted to an integer it follows the rules of integer arithmetic
instead of pointer arithmetic but the code doesn't do this.

> Show me a C compiler that breaks that behaviour, i.e. which breaks the logic
> of lookup_is_alive().

The standard permits such a compiler or rather such hardware. That's good
enough for me. It wouldn't be hard to modify an existing compiler to catch
exactly that i.e., abort the program if you try to load a pointer address
that doesn't correspond to allocated memory.

> :> Also, these pointers are always allocated as far as the implementation
> :> goes because they were allocated through malloc() underneath.  The walloc()
> :> layer on top of that merely redistributes the allocated space among 
> objects,
> :> but the space is not really freed.  None of this memory is really freed.
> :
> :A very poor excuse. walloc() is supposed to be transparent to malloc() and
> :you can compile gtk-gnutella so that it uses malloc() all the time. In
> :fact for debugging that's highly recommended and by not adhereing to
> :the standard you make just this more difficult.
> 
> Again, that would be Crappy, not C.  Now if I were to dereference a dangling
> pointer, that would be a severe bug and it would warrant an immediate fix.

I don't see the problem. On MS-DOS you can dereference any pointer you like.
Looks more like cherry-picking to me.

> P.S: Actually, that particular logic is older than you would think.

Knowing that you base your knowledge of C mainly on deprecated K&R this isn't
as surprising to me as you might have expected.

> And it has been running just fine for the past 4 years in gtk-gnutella 
> already.
> Just look at dq_alive().

Yeah, I already knew I had seen this elsewhere but two wrongs don't make a
right.

-- 
Christian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to