bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34151: [PATCH][bug 34151, 42393, 44795, 49755, 45205, 55073] Fix lex


From: Bogdan
Subject: bug#34151: [PATCH][bug 34151, 42393, 44795, 49755, 45205, 55073] Fix lex/yacc C++ tests on Solaris/SunOS
Date: Sun, 16 Apr 2023 18:37:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

Hi all.

The Solaris/SunOS lex generates C++ code with functions properly wrapped into >extern "C"<, but only if:

- compiling as C++ (__cplusplus is #defined),

- the feature constant __EXTERN_C__ is #defined (probably meant just for the SunOS compiler, not for all).

Other compilers, like GCC/G++, obviously miss the SunOS-specific __EXTERN_C__ and thus miss >extern "C"<, declaring the yylex() function as C++ (the default). This doesn't need to be a problem, but:

- the function should be declared as the user code expects it (as C for C programs and as C++ for C++ programs),

- the Automake lex tests for C++ re-declare the function always as a C function.

The re-declarations happens probably for good reason, like for lex implementations which don't declare the function in advance combined with C/C++ compilers which always require declarations. Unfortunately, having the same function declared as C++ (default) first and then later as C causes compiler errors.

 The attached patch corrects the declarations in the following way:

- if we're in C++ mode and __EXTERN_C__ is declared (so, we're on a SunOS with their compiler), declare the function as C in C++ mode (i.e., use >extern "C"<), just like the SunOS lex does,

- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also "__sun" is not declared (so, we're NOT on a SunOS), still assume C++ mode, but a different system and declare the function as C in C++ mode (i.e., use >extern "C"<) to support other compilers,

- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also "__sun" IS declared (so, we ARE on a SunOS, but not using their compiler), declare the function as C++ in C++ mode, just like the SunOS lex does,

- if we're NOT in C++ mode, declare the function as C. Not the case in these tests, though.

This should match what the SunOS lex/compiler do and expect which not braking other systems (re-checked on my Linux - works).

Verified that the defect exists on a Solaris 11.4 Build 15 (SunOS 5.11, GCC 7.3.0, amd64) and that the patch fixes it.

Furthermore, I checked how GCC manages the declarations of standard C functions in C++. Seems so simple as saying:

        using std::some_c_library_function_name;

which the SunOS library (or maybe just the old GCC library there) is not doing.
 So, it just takes this to fix the missing prototypes in C++ mode.

 In short, the patch:
- fixes the remaining part of https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34151, - fixes the remaining part of https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42393 (t/silent-many-languages.sh works for me),
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44795,
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49755,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45205,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55073.

Fortunately, these parts are just problems with the tests themselves, not with Automake in general.

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Attachment: automake-sunos2-mail.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]