[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison testing on Solaris (with FAILURES)
From: |
Stefano Lattarini |
Subject: |
Re: Bison testing on Solaris (with FAILURES) |
Date: |
Fri, 28 Jun 2013 11:40:03 +0200 |
On 06/28/2013 09:14 AM, Akim Demaille wrote:
> Hi Stefano,
>
> Le 26 juin 2013 à 12:42, Stefano Lattarini <address@hidden> a écrit :
>
>> On 06/26/2013 09:57 AM, Stefano Lattarini wrote:
>>> Hi Akim,
>>>
>>> On 06/24/2013 11:15 PM, Stefano Lattarini wrote:
>>>>
>>>> P.S. I'll *try* to run the bison testsuite on non-Linux systems
>>>> (Solaris 10, NetBSD 5.1 and FreeBSD 8.2), but I don't know if
>>>> I'll have time to do so, so don't hold your breath. Sorry :-(
>>>>
>> OK, tested on Solaris 10 with /bin/ksh as $CONFIG_SHELL, gcc 4.7.1
>> as C/C++ compilers, and /usr/ccs/bin/make as $MAKE. The build
>> succeeded, but there were several testsuite failures. I attach
>> the testsuite.log file (compressed). It seems all the failure
>> are due to the same issue:
>>
>> $(builddir)/lib/stdio.h:1025:1: error: 'char* gets(char*)' \
>> conflicts with previous using declaration \
>> 'char* std::gets(char*)'
>
>
>
>
>
> Well, I don't know what to do about this :( I suppose that line
> 1025 is something like this:
>
>> /* It is very rare that the developer ever has full control of stdin,
>> so any use of gets warrants an unconditional warning; besides, C11
>> removed it. */
>> #undef gets
>> #if HAVE_RAW_DECL_GETS
>> _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
>> #endif
>
Indeed:
$ sed -n 1024,1026p lib/stdio.h
#if HAVE_RAW_DECL_GETS
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
#endif
> that's the only occurrence of gets I found in lib/stdio.in.h.
>
>
> I could disable the C++ tests at test-suite runtime if the C++
> compiler is not happy with a simple #include <iostream>.
>
> I could also try to disable the use of gnulib in our test suite.
> Actually, since we are trying to check that our generated headers
> work properly and are reasonably portable, that would make a lot
> of sense. However I don't remember why the test suite started
> to use gnulib (it might even be by accident, I don't know), and I
> don't plan to spend time on detaching the test suite from gnulib
> right now.
>
> Do you see options I missed?
>
No, my knowledge of both C++ and the intertwining of Gnulib with
the Bison testsuite is basically zero. Sorry not to be of more
help.
Thanks,
Stefano