Comments on: gcc feature breaks glibc feature

By: David Schleef

David Schleef — Mon, 01 Oct 2007 19:32:21 +0000

This feature certainly would suck if I wanted to override printf() at some time. Maybe, say, when I was using gdb.

By: desrt

desrt — Mon, 01 Oct 2007 15:46:47 +0000

i’m not suggesting that i’d ever use “%s”, NULL in code intended to be portable (or even in production code). it’s just handy for debugging output and the like when you toss in a quick printf() to see what’s going on.

By: Havoc

Havoc — Mon, 01 Oct 2007 14:26:57 +0000

This glibc feature is nothing but annoying, since it’s unportable, all it does is keep you from noticing the bug until someone ports to another libc…

By: Qball

Qball — Mon, 01 Oct 2007 12:19:29 +0000

This “feature” has caused me headaches when cross-compiling/running programs on windows, there it will just crash.

By: blah

blah — Mon, 01 Oct 2007 12:09:10 +0000

Using a construct like printf(“%s”, NULL) in Gtk+ programs should be considered a bug anyway, unfortunately. On Solaris and other Unixes this construct will always cause a segfault.

I think GLib should provide something macroish like this:

static inline char *G_NONULLSTR(const char *s) {
return s ? s : “(null)”;
}

Then, people could just write:

printf(“%s\n”, G_NONULLSTR(s));

Which is relatively readable, safe and even type-safe.

On the Solaris printf() issue, see this:

http://mail.opensolaris.org/pipermail/opensolaris-code/2006-July/thread.html#2972

Unfortunately the Solaris people refused to copy glibc on this issue and kept their segfault-on-null printf implementation.

By: 1052

1052 — Mon, 01 Oct 2007 08:56:57 +0000

It seems obvious to me that glibc should handle puts() in the same way it handles printf(), and it should do the same with any other function that may print a null string. It is called consistency. So open a bug report there http://sources.redhat.com/bugzilla/enter_bug.cgi

By: Daniel Elstner

Daniel Elstner — Mon, 01 Oct 2007 08:05:02 +0000

most gnome hackers are probably accustomed to the fact that they can pass a null pointer as a value to glibc’s “%s” conversion character and get the string “(null)” output instead of a crash.

I take offense at that assertion!

Just kidding. Seriously though, this is definitely not something one should be accustomed to do. Not everyone is using GNU libc.

By: Aivars

Aivars — Mon, 01 Oct 2007 08:04:08 +0000

Printing NULL is a common crasher on SunOS and looks like AIX and HP-UX treat NULL as zero length string.
I agree with Matt that programmers must check for NULL pointers.

By: Matt Walton

Matt Walton — Mon, 01 Oct 2007 06:38:56 +0000

Surely you should be using printf(“%s\n”, s ? s : “(null)”); anyway? Relying on that feature of glibc is going to bite you next time you need to compile something against a C library which doesn’t behave like that.

It’s also possible it might encourage a cavalier attitude towards null pointers which is not reflected in other parts of the library or other libraries, leading to a lack of care and greater risk of segfaults. One thing programming commercially does teach is that too many people don’t pay attention to their pointers being null.

That said, by spec, is the optimisation valid in the defined behavioural cases? Best not to complain to the implementers about undefined ones – the language/library spec is at fault there.

Wouldn’t it be nice to live in a world where there were no undefined cases in C…

By: rwg

rwg — Mon, 01 Oct 2007 05:50:10 +0000

Unfortunately, the gcc folks seem unwilling to fix this since they say the results of printf(“%s\n”, NULL) are undefined:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685

(It would be nice to see consistency between gcc and glibc.)

It looks like your choices are -fno-builtin-printf or printf(“%s\n”, s ? s : “(null)”);