segmentations faults / x86-64 / stpcpy from dcgettext

[Michael Albert]

Greetings!

First, as always, let me say how much I really appreciate the
people who provide such nice tools as binutils.  I can not really
express how impressed I am by such things existing for free.
That said, I have found a small problem.

I attempted to compile binuitls-2.14 and binutils-2.15, but
the executables consistently gave segmentation faults, even
for "as --version".  The system is an AMD box running
Suse Professional 9.1, which comes with gcc-3.3.3, in 64-bit mode.
The segmentation faults occurs in stpcpy(), which is called from
dcgettext__.

The problem seems to be that if _GNU_SOURCE is not defined before
<features.h> is included, the compiler assumes that stpcpy() is
returning a 32-bit integer instead of a 64-bit pointer, so that
the pointer returned from stpcpy can not then be used as intended
to continue filling a given buffer.  Obviously, this depends upon
where the string is in memory.  The problem occurs because
<features.h> is included in many *.h files, so that unless _GNU_SOURCE
is defined at the top of the *.c file, it is likely that <features.h>
will be processed before _GNU_SOURCE is defined, with the result
that stpcpy() then is handled as if it returned a 32-bit quantity
instead of a 64-bit quantity.

At the risk of being tedious, I will give a few more details.

The declaration of stpcpy() is given in <string.h>, but is
surrounded by "#ifdef __USE_GNU/#endif".  The man--page for
stpcpy gives the following synopsis:

                           #define _GNU_SOURCE
                           #include <string.h>

The intention seems to be that <string.h> includes <features.h>, which
contains:
                     #ifdef _GNU_SOURCE
                     #define __USE_GNU  1
                     #endif

However, as noted above, <features.h> gets included in lots of files,
and if it is included before _GNU_SOURCE is defined, then the
first pass through <string.h> leaves __USE_GNU undefined
and stpcpy() returning a 32-bit quantity.  Of course, future passes
through <features.h> (such as when <string.h> is explicity included)
then have no effect.

In "intl/dcgettext.c", _GNU_SOURCE is apparently defined after
several other things are included, and, well, just about everything
ends up including features.h.  It is clear that the problem
can be solved by defining _GNU_SOURCE near the top of the file,
but currently the definition of _GNU_SOURCE is triggered by
"#if defined HAVE_STRING_H || defined _LIBC", so one has to know
where these might be defined, and I must admit I have not been able
to follow the myriad issues related to conditional configuration across
systems.

So, for now, I am contentedly running by simply inserting
__USE_GNU near the top of the file "intl/dcgettect.c".


Thank you!

Sincerely,
 Mike Albert