From: "David Kastrup" <dak@xxxxxxx>
Junio C Hamano <gitster@xxxxxxxxx> writes:
David Kastrup <dak@xxxxxxx> writes:
Hi, I am wondering if I may compare pointers with < that have been
created using different calls of malloc.
The C standard does not allow this (inequalities are only allowed
for
pointers into the same structure) to allow for some cheapskate sort
of
comparison in segmented architectures.
Hmm... if you were to implement a set of pointers in such a way that
you can cheaply tell if an unknown pointer belongs to that set, you
would use a hashtable, keyed with something that is derived from the
value of the pointer casted to uintptr_t, I would think.
The types intptr_t and uintptr_t are optional in ISO/IEC 9899:1999
(C99). So it would seem that I'd be covering fewer cases rather than
more in that manner.
I should think that architectures providing uintptr_t/intptr_t would
have very little incentive _not_ to offer pointer inequalities
equivalent to either the uintptr_t or intptr_t type conversion.
Undefined behaviours become hidden bugs of the future...
http://article.gmane.org/gmane.comp.version-control.git/230583
"blog on the problems of unexpected optimization bugs,
such as dereferencing a null pointer. "Finding Undefined Behavior Bugs
by Finding Dead Code" http://blog.regehr.org/archives/970 which links to
the draft of an interesting paper
http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf";
The code has now been released http://css.csail.mit.edu/stack/
https://github.com/xiw/stack/, and a few potential errors in Git were
caught by that tool by Stefan Beller.
The key point of the paper was never to try to use an 'obvious', but
undefined, behaviour.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html