[GNU Bison 2.3] testsuite: 103 104 failed

[Michael Deutschmann]

{I sent this message last August, but I recieved no response and the
message has not even appeared in the archives.  I suspect there may be
something in the list software that silently drops posts with large
attachments, so I've omitted the testsuite.log file this time.}

I've experienced some test failures after compiling bison 2.3, #103 and
#104.

I've investigated and found the cause.  The parser skeleton uses a local
version of the stpcpy() function, which is not standard but is present in
GLIBC, which only declares it if _GNU_SOURCE is defined.

The code tries to be clever and detect this circumstance automatically,
replacing the local yystpcpy() function with a reference to stpcpy() if
GLIBC is in use and _GNU_SOURCE is defined.  This avoids unneeded
namespace pollution, but takes advantage if the programmer already set
_GNU_SOURCE in his prologue region (between %{ and %}).

The trouble is, the C++ parser includes library headers before including
the prologue region.  After the first library header is loaded, the
setting of _GNU_SOURCE and related macros becomes effectively locked --
changing them will have no effect on what functions are declared.

So if _GNU_SOURCE is defined in the prologue of the .y file, it will have
no effect on the GLIBC headers.  But it will still be defined, fooling the
parser skeleton into assuming _GNU_SOURCE is in effect and stpcpy() is
available.

The code in tests #103/#104 effectively includes _GNU_SOURCE in the
headers (via "config.h").  The resulting C++ code attempts to use stpcpy()
without a declaration.  GCC makes incorrect assumptions about stpcpy()'s
argument and return types, and then refuses to compile the parser due to
typing violations.

Altering 'glr.c' to always use a local yystpcpy() allows all tests to
succeed.

---- Michael Deutschmann <address@hidden>