(Sorry about hashing the threading.)
Tom Horsley commented,
On Sun, 19 Jul 2009 11:49:42 -0700
Michael Eager wrote,
> OK, write a description of how to determine one case from the
> other and I'm sure every compiler developer will rush to
implement it.
The fact that they already have a -fno-delete-null-pointer-checks
option
in the compiler seems to demonstrate that they know they are doing
this specifically because it is undefined and they can do whatever
they want (including checking a compiler option to choose a different
thing to do). I guess thinking that the best choice is always
to do what the source code says makes me a member of a looney
minority though :-).
Well, the -fno-delete-null-pointer-checks option was intended for a
related, but different class of problems, specifically certain
application areas where it is defined to access NULL pointers. (The
standard does not define the behavior, but it isn't really against
the standard for a specific application field to define the behavior.
The code becomes non-standard C, however.)
(Specifically, embedded applications, although I tend to wonder if
the hardware design could not usually get around the reasons for
putting valid stuff in the bottom of memory. Actually, I'm beginning
to wonder, what with modern logical address spaces usually
significantly larger than applications need, whether it doesn't make
sense to devote address bits to the problems of classifying pointers.)
The C standard does not specify that every function returning a
pointer return invalid pointers. Moreover, it does not specify how to
determine a valid pointer, even though we customarily assume the NULL
pointer idiom.
I don't disagree that it feels awkward that they know the pointer has
been referenced and therefore would seem to be valid, thus, non-NULL,
but aren't able to back up the parse stack and see that the access
looks like a test-after-use bug.
Also, we humans walk back up parse stacks with relative ease, but it
slows compilers down to be walking back up the parse stack with
assumed valid code. I'm talking, worst case could be slow enough to
be completely unusable.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
