Bug#634261: weird if (&somesymbol) in eglibc
Note that taking the address of a symbol can never be NULL
according to C99, so the compiler may probably optimise
*all* of “if (&_IO_stdin_used == NULL) { … }” away. (That’s
because of the definition of NULL and object pointers.)
Maybe that’s what happens.
I agree something fishy is being done by eglibc here.
From /usr/include/libio.h this appears to be compatibility
code for glibc 2.0/2.1…
Reading “gcc foo.c -Wl,-t -static” with glibc is, compared
to other libcs, absolutely disgusting… but here we go.
/usr/lib/x86_64-linux-gnu/libc.a/uar://stdio.o (in new-mc
syntax) defines stdin and _IO_stdin in terms of _IO_2_1_stdin_
but doesn’t define _IO_stdin_used.
In fact, libc.a has no defintion of _IO_stdin_used *at all*,
and an nm on foo.o doesn’t show it either. (So where does it
come from? IMHO, if glibc insists on this hack, which probably
is “Undefined Behaviour” anyway, _IO_stdin_used should be
pulled in from stdio.o when linking on modernish glibcs.
bye,
//mirabilos, via Plänet Debian
--
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant. Therefore you cannot use ' in a preproces-
sing file in c99 mode. -- Ragge
No faith left in ISO C99, undefined behaviour, etc.
Reply to: