Re: *** %n in writable segment detected ***

[Bruno Haible]

[Removed bug-autoconf from the CC.]

Martin Walch wrote:

> > When using rather new versions of glibc (2.8...) and gcc (4.3.3), I get an
> > ugly warning on the screen during the execution of some configure scripts 
> > like
> > the ones from coreutils or m4.
> > ...
> > As soon as basic optimization is turned on (-O1), the warning is thrown.

In order to reproduce the problem, I also had to use
  ./configure CPPFLAGS=-D_FORTIFY_SOURCE=2

> > It says: 
> >
> > *** %n in writable segment detected ***

Confirmed. I see in the configure log:

  checking whether snprintf returns a byte count as in C99... yes
  checking whether snprintf fully supports the 'n' directive... *** %n in 
writable segment detected ***
  no

This is fine: it explains why on this glibc system, the snprintf is not fully 
ISO C99
compliant. The aesthetics of the output are not perfect, but that also happens 
in a
couple of other situations (such as when using AC_PROG_CC from autoconf 2.63 on
MacOS X 10.5).

> > and this is a warning that can not be suppressed by redirecting stdout or
> > stderr as glibc opens a new tty.

Confirmed. This is a problem with glibc. Why do they deem it best to ignore 
stderr and
instead open a tty? Why don't they use syslog for this purpose? Definitely 
something that
should be dealt with at glibc level.

> > I think it is a bad idea to get this warning from a configure script. It 
> > does
> > not appear in config.log but also can not be avoided. It confuses 
> > programmers
> > and non-programmers.

Yes, I agree with you. Error messages that bypass stderr are confusing.

> > Also, it should be possible to ignore any warning within 
> > a configure script as it should be save to ignore any warning or error that
> > shows up during a check.

The problem, as you explained, is that glibc sets up its error output in a way
that cannot be ignored or redirected.

Please talk to http://sourceware.org/bugzilla/ .

Bruno