Re: Static _Bool initialization

Michal Necasek <michaln@xxxxxxxxxxxxxxx> writes:
Keith Thompson wrote:
You might want to read section 5 of the comp.lang.c FAQ,
<http://www.c-faq.com/>.

If the C-FAQ is correct when it says (in 5.1) that "The address-of
operator & will never yield a null pointer" then all this is
irrelevant, because it'd mean that '(_Bool)&<foo>' has to be 1 for any
expression 'foo' allowable in that context.

Or is the C-FAQ misleading on this point?

The "&" operator will never yield a null pointer if its operand is
valid.

There's a loophole in the wording of the standard; it doesn't
explicitly exclude the possibility that an address just past the end
of an array could compare equal to a null pointer. There are
realistic scenarios in which this could happen. Doug Gwyn has said
here that it was not intended to allow this.

The code in the article that started this thread was:

extern int foo[];
_Bool bar = &foo[42];

If foo is an array of more than 42 elements, there's no problem;
&foo[42] is the address of an object, and it cannot be a null pointer.

If foo is an array of fewer than 42 elements, the expression invokes
undefined behavior, and the compiler can do whatever it likes,
including assigning the value 1 to bar.

If foo is an array of *exactly* 42 elements, the expression is an
address just past the end of the array. If the compiler (which can
make use of whatever system-specific knowledge it likes) happens to
know that this address cannot be null, there's no program; it can set
bar to 1. But if the compiler can't prove that (&foo[42] != NULL),
then it doesn't know whether bar should be set to 0 or 1.

This situation supports Doug Gwyn's point; allowing an address just
past the end of an array causes serious problems.

It's probably reasonable for any compiler to assume that sucn an
address cannot be null, rather than stubbornly following the literal
wording of the standard and ignoring the intent. This is a
sufficiently obscure issue that it's probably not worth mentioning in
the FAQ.

I do think that it's worth a DR and an official ruling from the
committee, with a mention in a future TR and in the next C standard,
but that needn't necessarily affect the behavior of any compiler. And
any compiler is free to guarantee that such addresses cannot be null,
even if the standard doesn't explicitly require it to do so.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.

Relevant Pages

  • Re: Need help to port VAX code to Alpha and to Itaninum
    ... Not really, the original code was wrong, and the compiler was not ... pointer to the start of the array. ... So you are trying to pass a pointer to a pointer to an array where you ... Also start looking at where you can add the "const" modifier to function ...
    (comp.os.vms)
  • Re: decrement past beginning is valid?
    ... > What I meant by legal is that a compiler will compile it. ... > that an array is the same as a pointer. ... behave the same way on all platforms. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: gdb not catching out-of-bounds pointer
    ... is also not defined by the C-standard, IOW: writing code in anything ... provided the library writer knows what the compiler writer guarantees ... etc.) that don't point into the same array than I would about the sort ... of pointer aliasing issue that started this sub-thread. ...
    (comp.unix.programmer)
  • Re: lockless file descriptor lookup
    ... It isn't clear whether you want to refresh the fd_ofiles pointer to the ... the array, or the fd'th element. ... This is actually intended to catch cases where the descriptor array has expanded and the pointer to fd_ofiles has changed, or the file has been closed and the pointer at the fd'th element has changed. ... I'm attempting to force the compiler to reload the fd_ofiles array pointer from the fdp structure. ...
    (freebsd-arch)
  • Re: null terminated strings
    ... pointer + 1 will point to the next element in the array. ... What I don't understand is why such a thing was included in any language that's more than an assembler. ... of structures that are not 'natural' the compiler need to generate ADD instructions using sizeof. ...
    (comp.os.vms)