This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: CPython cannot be compiled with -pedantic
Type: compile error Stage:
Components: Parser Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Dennis Sweeney, blastwave, lys.nikolaou, pablogsal
Priority: normal Keywords:

Created on 2021-07-30 23:47 by blastwave, last changed 2022-04-11 14:59 by admin.

Messages (13)
msg398612 - (view) Author: Dennis Clarke (blastwave) Date: 2021-07-30 23:47
With release 3.9.6 I see failures in compile on three
system architectures and with three compilers. I did
check with GCC 10.2.1 ( Debian 10.2.1-6 ) on IBM Power and
also with FreeBSD UNIX LLVM/Clang 12.0.1 on AMD64 and also
with Oracle Studio C99 strict in Solaris UNIX on Fujitsu
SPARC64 wherein we see a consistent fail within the source :

    Parser/pegen/pegen.c

This is due to a standards compliance failure as per section
6.10.3 Macro replacement. Please see constraints item 4.

This fails to compile on Solaris 10 UNIX, FreeBSD 14.0 AMD64 
and on Debian Linux. 


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
msg398614 - (view) Author: Dennis Sweeney (Dennis Sweeney) * (Python committer) Date: 2021-07-31 01:04
To be specific, is this about the fact that .arg is a member of `struct _arg` (typedef'ed as `arg_ty`), while at the same time arg() is a macro?

as in: https://github.com/python/cpython/blob/0f42b726c87f72d522893f927b4cb592b8875641/Parser/pegen/pegen.c#L37
msg398616 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-31 01:25
Dennis Clarke, thanks for the report. Unfortunately we don't know how to reproduce the problems you mention. Could you please indicate what are you running? For instance, I can compile with 11.1.0 with absolutely no problems here.
msg398634 - (view) Author: Dennis Clarke (blastwave) Date: 2021-07-31 12:11
Let me see if I can be a bit more clear with the problem that I am
seeing on three separate systems. It does seem to be an issue in
a macro  : 

1) Debian Linux on IBM Power ppc64 big-endian : 

enceladus$ uname -a 
Linux enceladus 5.13.4-genunix #1 SMP Tue Jul 20 12:42:08 EDT 2021 ppc64 GNU/Linux
enceladus$ gcc --version 
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

enceladus$ 
enceladus$ 
enceladus$ ls Parser/pegen/pegen.c Parser/pegen/pegen.h
Parser/pegen/pegen.c  Parser/pegen/pegen.h
enceladus$ 
enceladus$ /usr/bin/gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG \
> -fwrapv -Wall -std=iso9899:1999 -pedantic -g -O0 -fno-builtin -m64 \
> -mno-quad-memory-atomic -mfull-toc -mno-multiple -mupdate -mbig \
> -mregnames -fno-unsafe-math-optimizations -pedantic-errors \
> -Wextra -Wno-unused-result -Wno-unused-parameter \
> -Wno-missing-field-initializers \
> -Werror=implicit-function-declaration \
> -fvisibility=hidden \
> -I./Include/internal -I. -I./Include \
> -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE \
> -DPy_BUILD_CORE -o Parser/pegen/pegen.o Parser/pegen/pegen.c
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h: In function ‘_RAISE_SYNTAX_ERROR_INVALID_TARGET’:
Parser/pegen/pegen.h:297:47: error: ISO C99 requires at least one argument for the "..." in a variadic macro
  297 |     return RAISE_SYNTAX_ERROR("invalid syntax");
      |                                               ^
Parser/pegen/pegen.c: In function ‘_PyPegen_check_barry_as_flufl’:
Parser/pegen/pegen.c:71:74: error: ISO C99 requires at least one argument for the "..." in a variadic macro
   71 |         RAISE_SYNTAX_ERROR("with Barry as BDFL, use '<>' instead of '!='");
      |                                                                          ^
Parser/pegen/pegen.c: In function ‘tokenizer_error’:
Parser/pegen/pegen.c:323:81: error: ISO C99 requires at least one argument for the "..." in a variadic macro
  323 |             RAISE_SYNTAX_ERROR("EOF while scanning triple-quoted string literal");
      |                                                                                 ^
Parser/pegen/pegen.c:326:67: error: ISO C99 requires at least one argument for the "..." in a variadic macro
  326 |             RAISE_SYNTAX_ERROR("EOL while scanning string literal");
      |                                                                   ^
Parser/pegen/pegen.c:329:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
  329 |             RAISE_SYNTAX_ERROR("unexpected EOF while parsing");
      |                                                              ^
Parser/pegen/pegen.c:332:90: error: ISO C99 requires at least one argument for the "..." in a variadic macro
  332 |             RAISE_INDENTATION_ERROR("unindent does not match any outer indentation level");
      |                                                                                          ^
Parser/pegen/pegen.c: In function ‘_PyPegen_number_token’:
Parser/pegen/pegen.c:953:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
  953 |                                   "in Python 3.6 and greater");
      |                                                              ^
Parser/pegen/pegen.c: In function ‘_PyPegen_run_parser’:
Parser/pegen/pegen.c:1132:73: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 1132 |             RAISE_SYNTAX_ERROR("error at start before reading any input");
      |                                                                         ^
Parser/pegen/pegen.c:1135:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 1135 |             RAISE_SYNTAX_ERROR("unexpected EOF while parsing");
      |                                                              ^
Parser/pegen/pegen.c:1139:60: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 1139 |                 RAISE_INDENTATION_ERROR("unexpected indent");
      |                                                            ^
Parser/pegen/pegen.c:1142:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 1142 |                 RAISE_INDENTATION_ERROR("unexpected unindent");
      |                                                              ^
Parser/pegen/pegen.c:1145:52: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 1145 |                 RAISE_SYNTAX_ERROR("invalid syntax");
      |                                                    ^
Parser/pegen/pegen.c:1153:97: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 1153 |         return RAISE_SYNTAX_ERROR("multiple statements found while compiling a single statement");
      |                                                                                                 ^
Parser/pegen/pegen.c: In function ‘_PyPegen_concatenate_strings’:
Parser/pegen/pegen.c:2053:72: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 2053 |             RAISE_SYNTAX_ERROR("cannot mix bytes and nonbytes literals");
      |                                                                        ^
Parser/pegen/pegen.c: In function ‘_PyPegen_arguments_parsing_error’:
Parser/pegen/pegen.c:2212:34: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 2212 |     return RAISE_SYNTAX_ERROR(msg);
      |                                  ^
Parser/pegen/pegen.c: In function ‘_PyPegen_nonparen_genexp_in_call’:
Parser/pegen/pegen.c:2233:5: error: ISO C99 requires at least one argument for the "..." in a variadic macro
 2233 |     );
      |     ^
enceladus$ 


2) On FreeBSD UNIX with AMD64 and LLVM/Clang : 

europa$ uname -apKU 
FreeBSD europa 14.0-CURRENT FreeBSD 14.0-CURRENT #3: Sun Jul 25 13:50:33 GMT 2021     root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64 amd64 1400026 1400026
europa$ 
europa$ cc --version 
FreeBSD clang version 12.0.1 (git@github.com:llvm/llvm-project.git llvmorg-12.0.1-0-gfed41342a82f)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin

europa$ 
europa$ ls Parser/pegen/pegen.c Parser/pegen/pegen.h
Parser/pegen/pegen.c    Parser/pegen/pegen.h
europa$ 
europa$ /usr/bin/cc -pthread -c -fno-strict-aliasing -Wsign-compare \
> -Wunreachable-code -DNDEBUG -g -fwrapv -Wall -std=iso9899:1999 \
> -pedantic -pedantic-errors -Weverything -Wno-reserved-id-macro \
> -Wno-missing-prototypes -m64 -O0 -fno-fast-math -fno-builtin \
> -Werror=implicit-function-declaration -fvisibility=hidden \
> -I./Include/internal -I. -I./Include \
> -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE \
> -DPy_BUILD_CORE -o Parser/pegen/pegen.o Parser/pegen/pegen.c
In file included from Parser/pegen/pegen.c:1:
In file included from ./Include/Python.h:94:
In file included from ./Include/pytime.h:6:
In file included from ./Include/object.h:615:
./Include/cpython/object.h:272:16: warning: padding struct 'struct _typeobject' with 4 bytes to align
      'tp_finalize' [-Wpadded]
    destructor tp_finalize;
               ^
In file included from Parser/pegen/pegen.c:1:
In file included from ./Include/Python.h:106:
In file included from ./Include/unicodeobject.h:1026:
./Include/cpython/unicodeobject.h:218:14: warning: padding struct 'PyASCIIObject' with 4 bytes to align 'wstr'
      [-Wpadded]
    wchar_t *wstr;              /* wchar_t representation (null-terminated) */
             ^
In file included from Parser/pegen/pegen.c:5:
In file included from Parser/pegen/pegen.h:7:
./Include/Python-ast.h:239:23: warning: padding struct 'struct _expr::(anonymous at
      ./Include/Python-ast.h:237:9)' with 4 bytes to align 'values' [-Wpadded]
            asdl_seq *values;
                      ^
./Include/Python-ast.h:452:20: warning: padding struct 'struct _type_ignore::(anonymous at
      ./Include/Python-ast.h:450:9)' with 4 bytes to align 'tag' [-Wpadded]
            string tag;
                   ^
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:157:86: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                     ^
Parser/pegen/pegen.h:160:89: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
    RAISE_ERROR_KNOWN_LOCATION(p, PyExc_SyntaxError, (a)->lineno, (a)->col_offset, msg, ##__VA_ARGS__)
                                                                                        ^
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.c:12:45: warning: implicit conversion changes signedness: 'size_t' (aka 'unsigned long') to
      'Py_ssize_t' (aka 'long') [-Wsign-conversion]
    PyObject *res = PyUnicode_DecodeUTF8(s, strlen(s), NULL);
                    ~~~~~~~~~~~~~~~~~~~~    ^~~~~~~~~
In file included from Parser/pegen/pegen.c:1:
In file included from ./Include/Python.h:105:
In file included from ./Include/bytesobject.h:75:
./Include/cpython/bytesobject.h:5:9: warning: padding size of 'PyBytesObject' with 7 bytes to alignment
      boundary [-Wpadded]
typedef struct {
        ^
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.c:83:44: warning: implicit conversion changes signedness: 'size_t' (aka 'unsigned long') to
      'Py_ssize_t' (aka 'long') [-Wsign-conversion]
    PyObject *id = PyUnicode_DecodeUTF8(n, strlen(n), NULL);
                   ~~~~~~~~~~~~~~~~~~~~    ^~~~~~~~~
In file included from Parser/pegen/pegen.c:1:
In file included from ./Include/Python.h:108:
./Include/longintrepr.h:85:8: warning: padding size of 'struct _longobject' with 4 bytes to alignment boundary
      [-Wpadded]
struct _longobject {
       ^
Parser/pegen/pegen.c:163:13: warning: enumeration value 'Slice_kind' not explicitly handled in switch
      [-Wswitch-enum]
    switch (e->kind) {
            ^
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:157:86: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                     ^
Parser/pegen/pegen.h:157:86: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
Parser/pegen/pegen.h:158:94: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_INDENTATION_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_IndentationError, msg, ##__VA_ARGS__)
                                                                                             ^
Parser/pegen/pegen.c:351:60: warning: implicit conversion changes signedness: 'unsigned long' to 'Py_ssize_t'
      (aka 'long') [-Wsign-conversion]
            col_offset = strlen(strtok(p->tok->buf, "\n")) - 1;
                       ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
Parser/pegen/pegen.c:396:46: warning: implicit conversion changes signedness: 'unsigned long' to 'Py_ssize_t'
      (aka 'long') [-Wsign-conversion]
        Py_ssize_t len = strlen(fstring_msg) + strlen(errmsg);
                   ~~~   ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
Parser/pegen/pegen.c:398:48: warning: implicit conversion changes signedness: 'long' to 'size_t'
      (aka 'unsigned long') [-Wsign-conversion]
        char *new_errmsg = PyMem_RawMalloc(len + 1); // Lengths of both strings plus NULL character
                           ~~~~~~~~~~~~~~~ ~~~~^~~
Parser/pegen/pegen.c:449:31: warning: cast from 'const char *' to 'void *' drops const qualifier [-Wcast-qual]
        PyMem_RawFree((void *)errmsg);
                              ^
Parser/pegen/pegen.c:457:31: warning: cast from 'const char *' to 'void *' drops const qualifier [-Wcast-qual]
        PyMem_RawFree((void *)errmsg);
                              ^
Parser/pegen/pegen.c:535:35: warning: implicit conversion changes signedness: 'int' to 'size_t'
      (aka 'unsigned long') [-Wsign-conversion]
        if (strncmp(k->str, name, name_len) == 0) {
            ~~~~~~~               ^~~~~~~~
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:50:15: warning: padding struct 'struct growable_comment_array::(anonymous at
      Parser/pegen/pegen.h:48:5)' with 4 bytes to align 'comment' [-Wpadded]
        char *comment;  // The " <tag>" in "# type: ignore <tag>"
              ^
Parser/pegen/pegen.c:588:38: warning: implicit conversion changes signedness: 'long' to 'size_t'
      (aka 'unsigned long') [-Wsign-conversion]
        char *tag = PyMem_Malloc(len + 1);
                    ~~~~~~~~~~~~ ~~~~^~~
Parser/pegen/pegen.c:593:29: warning: implicit conversion changes signedness: 'Py_ssize_t' (aka 'long') to
      'size_t' (aka 'unsigned long') [-Wsign-conversion]
        strncpy(tag, start, len);
        ~~~~~~~             ^~~
Parser/pegen/pegen.c:618:55: warning: implicit conversion changes signedness: 'int' to 'unsigned long'
      [-Wsign-conversion]
        Token **new_tokens = PyMem_Realloc(p->tokens, newsize * sizeof(Token *));
                                                      ^~~~~~~ ~
Parser/pegen/pegen.c:877:44: warning: cast from 'const char *' to 'char *' drops const qualifier [-Wcast-qual]
        x = (long)PyOS_strtoul(s, (char **)&end, 0);
                                           ^
Parser/pegen/pegen.c:883:37: warning: cast from 'const char *' to 'char *' drops const qualifier [-Wcast-qual]
        x = PyOS_strtol(s, (char **)&end, 0);
                                    ^
Parser/pegen/pegen.c:894:56: warning: cast from 'const char *' to 'char *' drops const qualifier [-Wcast-qual]
        compl.imag = PyOS_string_to_double(s, (char **)&end, NULL);
                                                       ^
Parser/pegen/pegen.c:895:24: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
        if (compl.imag == -1.0 && PyErr_Occurred()) {
            ~~~~~~~~~~ ^  ~~~~
Parser/pegen/pegen.c:901:12: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
    if (dx == -1.0 && PyErr_Occurred()) {
        ~~ ^  ~~~~
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.h:61:14: warning: padding struct 'Parser' with 4 bytes to align 'arena' [-Wpadded]
    PyArena *arena;
             ^
Parser/pegen/pegen.h:67:15: warning: padding struct 'Parser' with 4 bytes to align 'normalize' [-Wpadded]
    PyObject* normalize;
              ^
Parser/pegen/pegen.h:73:28: warning: padding struct 'Parser' with 4 bytes to align 'type_ignore_comments'
      [-Wpadded]
    growable_comment_array type_ignore_comments;
                           ^
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
Parser/pegen/pegen.h:158:94: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_INDENTATION_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_IndentationError, msg, ##__VA_ARGS__)
                                                                                             ^
Parser/pegen/pegen.h:158:94: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
Parser/pegen/pegen.c:1382:61: warning: implicit conversion changes signedness: 'unsigned long' to 'Py_ssize_t'
      (aka 'long') [-Wsign-conversion]
    Py_ssize_t len = strlen(first_str) + strlen(second_str) + 1;  // +1 for the dot
               ~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
Parser/pegen/pegen.c:1496:40: warning: implicit conversion changes signedness: 'cmpop_ty' (aka 'enum _cmpop')
      to 'int' [-Wsign-conversion]
        asdl_seq_SET(new_seq, i, pair->cmpop);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
./Include/asdl.h:42:51: note: expanded from macro 'asdl_seq_SET'
#define asdl_seq_SET(S, I, V) (S)->elements[I] = (V)
                                               ~  ^
Parser/pegen/pegen.c:1581:13: warning: 21 enumeration values not explicitly handled in switch: 'BoolOp_kind',
      'NamedExpr_kind', 'BinOp_kind'... [-Wswitch-enum]
    switch (expr->kind) {
            ^
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
Parser/pegen/pegen.c:2115:46: warning: implicit conversion changes signedness: 'size_t' (aka 'unsigned long')
      to 'Py_ssize_t' (aka 'long') [-Wsign-conversion]
    Py_ssize_t num = p->type_ignore_comments.num_items;
               ~~~   ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
Parser/pegen/pegen.c:2163:13: warning: 20 enumeration values not explicitly handled in switch: 'BoolOp_kind',
      'NamedExpr_kind', 'BinOp_kind'... [-Wswitch-enum]
    switch (e->kind) {
            ^
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h:157:84: error: token pasting of ',' and __VA_ARGS__ is a GNU extension
      [-Werror,-Wgnu-zero-variadic-macro-arguments]
#define RAISE_SYNTAX_ERROR(msg, ...) _PyPegen_raise_error(p, PyExc_SyntaxError, msg, ##__VA_ARGS__)
                                                                                   ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
32 warnings and 20 errors generated.
europa$ 


3) Solaris 10 UNIX with Oracle Studio 12.6 on Fujitsu SPARC64

beta $ 
beta $ uname -a 
SunOS beta 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise
beta $ cc -V
cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30
beta $ c99 -V
c99: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30
beta $ /opt/developerstudio12.6/bin/c99 -c -DNDEBUG -Xc -errtags=yes \
-errwarn=%none -m64 -xarch=sparc -xO0 -g -xs -errfmt=error \
-erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s \
-xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc \
-ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf \
-D_REENTRANT \
-I./Include/internal -I. -I./Include -I/opt/bw/include \
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO \
-D_FILE_OFFSET_BITS=64 \
-DPy_BUILD_CORE -o Parser/pegen/pegen.o Parser/pegen/pegen.c
"Parser/pegen/pegen.h", line 297: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.h", line 297: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 71: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 71: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 323: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 323: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 326: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 326: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 329: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 329: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 332: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 332: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 952: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 952: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 1132: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 1132: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 1135: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 1135: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 1139: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 1139: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 1142: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 1142: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 1145: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 1145: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 1153: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 1153: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 2053: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 2053: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 2212: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 2212: error: syntax error before or at: )
"Parser/pegen/pegen.c", line 2230: warning: argument mismatch (E_ARGUEMENT_MISMATCH)
"Parser/pegen/pegen.c", line 2230: error: syntax error before or at: )
c99: acomp failed for Parser/pegen/pegen.c
beta $ 

Also for the sake of some added flavour here we can look at Debian on
AMD64 with whatever tools we get in Debian stable. I ran a trivial
configure "./configure --without-pymalloc --prefix=/home/dclarke/local"
and see the same failure.

deimos$ 
deimos$ uname -a 
Linux deimos 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
deimos$ gcc --version 
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

deimos$ 

Then during make : 

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=iso9899:1999 -pedantic -pedantic-errors -m64 -g -O0 -fno-builtin -march=k8 -mtune=k8 -mieee-fp -fno-fast-math -std=iso9899:1999 -pedantic -pedantic-errors -m64 -g -O0 -fno-builtin -march=k8 -mtune=k8 -mieee-fp -fno-fast-math  -std=iso9899:1999 -pedantic -pedantic-errors -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -DPy_BUILD_CORE -o Parser/pegen/pegen.o Parser/pegen/pegen.c
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h: In function '_RAISE_SYNTAX_ERROR_INVALID_TARGET':
Parser/pegen/pegen.h:297:47: error: ISO C99 requires at least one argument for the "..." in a variadic macro
     return RAISE_SYNTAX_ERROR("invalid syntax");
                                               ^
Parser/pegen/pegen.c: In function '_PyPegen_check_barry_as_flufl':
Parser/pegen/pegen.c:71:74: error: ISO C99 requires at least one argument for the "..." in a variadic macro
         RAISE_SYNTAX_ERROR("with Barry as BDFL, use '<>' instead of '!='");
                                                                          ^
Parser/pegen/pegen.c: In function 'tokenizer_error':
Parser/pegen/pegen.c:323:81: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_SYNTAX_ERROR("EOF while scanning triple-quoted string literal");
                                                                                 ^
Parser/pegen/pegen.c:326:67: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_SYNTAX_ERROR("EOL while scanning string literal");
                                                                   ^
Parser/pegen/pegen.c:329:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_SYNTAX_ERROR("unexpected EOF while parsing");
                                                              ^
Parser/pegen/pegen.c:332:90: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_INDENTATION_ERROR("unindent does not match any outer indentation level");
                                                                                          ^
Parser/pegen/pegen.c: In function '_PyPegen_number_token':
Parser/pegen/pegen.c:953:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
                                   "in Python 3.6 and greater");
                                                              ^
Parser/pegen/pegen.c: In function '_PyPegen_run_parser':
Parser/pegen/pegen.c:1132:73: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_SYNTAX_ERROR("error at start before reading any input");
                                                                         ^
Parser/pegen/pegen.c:1135:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_SYNTAX_ERROR("unexpected EOF while parsing");
                                                              ^
Parser/pegen/pegen.c:1139:60: error: ISO C99 requires at least one argument for the "..." in a variadic macro
                 RAISE_INDENTATION_ERROR("unexpected indent");
                                                            ^
Parser/pegen/pegen.c:1142:62: error: ISO C99 requires at least one argument for the "..." in a variadic macro
                 RAISE_INDENTATION_ERROR("unexpected unindent");
                                                              ^
Parser/pegen/pegen.c:1145:52: error: ISO C99 requires at least one argument for the "..." in a variadic macro
                 RAISE_SYNTAX_ERROR("invalid syntax");
                                                    ^
Parser/pegen/pegen.c:1153:97: error: ISO C99 requires at least one argument for the "..." in a variadic macro
         return RAISE_SYNTAX_ERROR("multiple statements found while compiling a single statement");
                                                                                                 ^
Parser/pegen/pegen.c: In function '_PyPegen_concatenate_strings':
Parser/pegen/pegen.c:2053:72: error: ISO C99 requires at least one argument for the "..." in a variadic macro
             RAISE_SYNTAX_ERROR("cannot mix bytes and nonbytes literals");
                                                                        ^
Parser/pegen/pegen.c: In function '_PyPegen_arguments_parsing_error':
Parser/pegen/pegen.c:2212:34: error: ISO C99 requires at least one argument for the "..." in a variadic macro
     return RAISE_SYNTAX_ERROR(msg);
                                  ^
Parser/pegen/pegen.c: In function '_PyPegen_nonparen_genexp_in_call':
Parser/pegen/pegen.c:2233:5: error: ISO C99 requires at least one argument for the "..." in a variadic macro
     );
     ^
make: *** [Makefile:1803: Parser/pegen/pegen.o] Error 1
deimos$ 

So I can not get 3.9.6 to compile on any of four systems.
msg398635 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-31 12:19
Seems to me that you are not only running configure + make but you are adding things to the CFLAGS. Could you please add a list of all the extra complication flags you are adding?
msg398663 - (view) Author: Dennis Clarke (blastwave) Date: 2021-07-31 20:55
This was an excellent opportunity to review these CFLAGS and to
ponder the value of each. This took me a day to write and was
then reviewed by a team. I hope it answers your question.

---------------------------------------------------------------

There is nothing too unusual in the CFLAGS on any system. I have
used this sort of config for many years without too many problems.
There are always some open source software packages that are a bit
"special" and one can not expect strictly portable code everywhere.
However some packages are really critical and Python would be one
of those certainly. We have to agree that the usage of some gnu
extensions breaks "-pedantic" always.

Let us go over these compiler flags for a Solaris 10 SPARC64 system.

beta $ echo $CC
/opt/developerstudio12.6/bin/c99

    Clearly that is the C99 compiler. Similar to running f77 in order
    to handle Fortran77 code.  However the f77 is just a symlink these
    days and it points to f90.  Such is life in the modern world.


CFLAGS ?

I guess we can go over these one by one however they are all clearly
documented in the "Oracle(R) Developer Studio 12.6: C User's Guide" which
we may see here :

    https://docs.oracle.com/cd/E77782_01/html/E77788/index.html

There is a fairly extensive discussion regarding "Features of C 99" :

    https://docs.oracle.com/cd/E77782_01/html/E77788/bjayy.html

OKay lets look at these flags that I have used almost everywhere for
many years :

    -Xc  is seen in section B.2.84 :

        (c = conformance) Issues errors and warnings for programs
        that use non-ISO C constructs. This option is strictly
        conformant ISO C without K&R C compatibility extensions.

        As a side comment here the compiler in use is C99 and this
        option is somewhat similar to saying "-pedantic" and yes I
        really do mean iso9899:1999 without any special flavour
        sauce added :)

        The documentation states :

           See D.1 for a discussion of supported 1999 ISO/IEC features.
           See Appendix H for a discussion of differences between
           ISO/IEC C and K&R C.

           All of that discussion is in the links above.


    -errtags=yes -errwarn=%none -errfmt=error
    -erroff=%none -errshort=full

        Lets look at these as a group of options that ensure we get a
        really verbose error message when needed.

        From section B.2.12 we see -errfmt[=[no%]error] which is used
        if you want to prefix the string "error:" to the beginning of
        error messages so they are more easily distinguishable from
        warning messages. The prefix is also attached to warnings that
        are converted to errors by -errwarn.

        Section B.2.17 we see -errwarn[=t] where I use t=%none such that
        "... any warning message from causing the compiler to exit with
         a fatal status should any warning message be issued."

        Around the same section we see -errtags=a for a being either a
        yes or no. From the manual "Displays the message tag for each
        warning message of the C compiler that can be suppressed with
        the -erroff option or made a fatal error with the -errwarn
        option."

        This brings us to the -erroff flag discussed in section B.2.14
        where it simply says %none enables all warning messages.

        Finally there is -errshort which will determine how much data we
        get from an error message. The option "full" should be pretty clear
        and the section B.2.15 states "Error messages are printed with
        tag names for types which have tag names. If there is no tag
        name, the type is shown in expanded form."

    -m64 -xarch=sparc

        These are trivial and merely specify that we are building for a
        64 bit platform and the target architecture is a SPARC. In this
        specific case we are using a Fujitsu SPARC64 based server where
        the full cpu description would be SPARC64-VII+ clock 2860 MHz.

    -xO0 -g -xs

        The -xO0 option is similar to what we see from GCC and LLVM/Clang
        and other compilers. The compiler optimization level where here
        we use a zero and this is not documented. It is in fact the default
        and the compiler accepts this flag just fine. Any other number from
        1 upwards to 5 indicates a level of optimization that is ever more
        complex. To be blunt the use of a debugging switch -g with any level
        of optimization above 2 will result in limited debug data. Section
        B.2.150 lays out everything one would want to know for the SPARC and
        AMD64 platforms.

        The -xs option is a bit special in that it allows debug information
        to be encoded into the executable binaries. Section B.2.172 shows
        us the default is in fact -xs=yes. This is the same and simply -xs
        by itself. When the compile command forces linking (that is, -c is
        not specified) there will be no object file(s) and the debug info
        must be placed in the executable. I tend to always have -xs with the
        -g option and I do specify the -xO0 just to be really clear at a
        glance that this is a non-optimized debug build.

    -xstrconst

        Strangely this is a deprecated option that seems to be silently
        accepted. I have had this in my CFLAGS for at least twenty years
        and never had a problem. It still works and as section B.2.178
        says it "might be removed in a future release."  The manual suggests
        that we replace this switch with -features=conststrings which is
        documented in section B.2.20 thus :

            Enables the placement of string literals in read-only memory.
            The default is –features=conststrings which places string
            literals into the read-only data section. Note that compiling
            a program that attempts to write to the memory location of a
            string literal will now cause a segmentation fault when compiled
            with this option. no% prefix disables this sub-option.

    -xildoff

        This is an oldie but a goodie as they say. Not even documented in
        the Oracle copy of the manual. Older manual revisions simply say :

            Turns off the incremental linker and forces the use of ld.

        Which is what I want. Also I can set LD_foo flags if needed and
        those are fully respected by ld.  We may find this option mentioned
        here :

            https://docs.oracle.com/cd/E19957-01/806-3567/cc_options.html

    -xmemalign=8s

        Somewhat complicated but this flag suggests alignment of data to
        the compiler. The flag requires two options where the first is a
        number to suggest "at most X byte alignment" and the second is a
        flag to suggest behavior in the event of a misaligned access where
        the "s" means "Raise signal SIGBUS." This makes for an easy way to
        detect bad behavior as a sigbus is hard to miss on a machine where
        the operating system will trap the signal and then generate a core
        dump with all the data you could ask for. I have consistently used
        this alignment flag for years and ALL libraries are built with it.

    -xnolibmil

        Trivial. Do not inline math library routines.  This may allow for
        more easy debugging later. Maybe. If I want to go with optimization
        then of course we inline.

    -xcode=pic32

        From section B.2.103 we may specify code address space. Here I use
        "pic32" which results in :

            Generates position-independent code for use in shared
            libraries (large model). Equivalent to -KPIC. Permits
            references to at most 2**30 unique external symbols on
            32-bit architectures, 2**29 on 64-bit architectures.

        There is a reasonable discussion about this in the manual of course.
        It is worth reading some key features here :

            A routine compiled with either -xcode=pic13 or -xcode=pic32
            executes a few extra instructions upon entry to set a
            register to point at a table (_GLOBAL_OFFSET_TABLE_) used
            for accessing a shared library’s global or static variables.

            Each access to a global or static variable involves an extra
            indirect memory reference through _GLOBAL_OFFSET_TABLE_. If
            the compilation includes -xcode=pic32, there are two
            additional instructions per global and static memory reference.

            When considering these costs, remember that the use of
            -xcode=pic13 and -xcode=pic32 can significantly reduce system
            memory requirements due to the effect of library code sharing.
            Every page of code in a shared library compiled -xcode=pic13
            or -xcode=pic32 can be shared by every process that uses the
            library. If a page of code in a shared library contains even
            a single non-pic (that is, absolute) memory reference, the
            page becomes nonsharable, and a copy of the page must be
            created each time a program using the library is executed.

        Therefore it seems very reasonable that code compiled on a 64bit
        system will be done with -xcode=pic32.

    -xregs=no%appl

        See section B.2.170 where we may specify the usage of registers
        for the generated code. I suggest not to use the application
        registers g2 and g3. The manual suggests "You should compile all
        system software and libraries using -xregs=no%appl."  Well golly
        gee that is just what I do. Why?

            System software (including shared libraries) must preserve
            these registers’ values for the application. Their use is
            intended to be controlled by the compilation system and
            must be consistent throughout the application.

        Clearly I am creating shared libs to be used in many ways long
        term.

    -xlibmieee

        This is trivial. In section B.2.131 we see :

            Forces IEEE 754 style return values for math routines in
            exceptional cases. In such cases, no exception message is
            printed, and you should not rely on errno.

        Generally when I work with floating point it is best to use
        the provided methods to detect fp-exceptions. Which certainly
        do happen ALL the time.

    -mc

        Trivial. From section B.2.55 we see :

            Removes duplicate strings from the .comment section of
            the object file. When you use the -mc flag, mcs -c is
            invoked.

    -ftrap=%none

        This flag seems to be confused in that one would think it means
        we do NOT trap any floating point exceptions. However this is
        entirely the opposite.  There are a pile of options here and in
        section B.2.37 we see we can trap everything and get a SIGFPE
        along with our own handler.  I find it is far better to check
        for floating point exceptions in my code and then deal with the
        issues without a SIGFPE :

            [no%]division          Trap on division by zero.
            [no%]inexact           Trap on inexact result.
            [no%]invalid           Trap on invalid operation.
            [no%]overflow          Trap on overflow.
            [no%]underflow         Trap on underflow.
            %all                   Trap on all of the above.
            %none                  Trap on none of the above.
            common                 Trap on invalid, division by zero,
                                       and overflow.

        You can use ieee_handler(3M) or fex_set_handling(3M) to
        simultaneously enable traps and install a SIGFPE handler.

        If you do not specify -ftrap, the compiler assumes -ftrap=%none.

        So clearly I am being a bit verbose but at least there is no
        confusion about what is happening.

    -xbuiltin=%none

        In section B.2.95 we see where we can choose to inline some
        common library calls, or not. Since I am doing a debug and
        entirely non-optimized build here there is no reason to
        inline anything.  So I don't. :)

    -xunroll=1

        Section B.2.187 allows us to suggest to the compiler that it
        can unroll loops.  When n is 1, it requires the compiler not
        to unroll loops. Pretty clear and also useful when debugging.

    -Qy

        Section B.2.69 tells us that -Qy is the default in any case and
        it determines whether to emit identification information to the
        output file. Generally very helpful to know every header as well
        as the tools that made a binary.  Use mcs -p to print out loads
        of information from a binary that has not been stripped.

I did take a look at https://www.python.org/dev/peps/pep-0007/  where
we are clearly told to not use GNU extensions and that the code should
be C89 clean with a few C99 features for everything recent.

So this did take a day to write and it was a valuable exercise both for
myself and a number of people who did review.
msg398664 - (view) Author: Dennis Clarke (blastwave) Date: 2021-07-31 20:56
Minor note. I am going to change the component to the Parser.
msg398668 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-31 22:59
You cannot compile CPython with `-pedantic`. For example, if i add that to my collection of CFLAGS with gcc 11, many object files do not compile (too many to report here). That is not a supported compilation flag and certainly this problem is not only about the parser.

I would suggest to close this issue and maybe reopen another one regarding "CPython doesn't compile with -pedantic".
msg398669 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-31 23:02
For example, if I remove -Werror, you will get tons of warnings that will eventually become errors even if the parser code is "fixed":

./Modules/posixmodule.c:13781:18: note: (near initialization for ‘DirEntryType_slots[1].pfunc’)
./Modules/posixmodule.c: In function ‘ScandirIterator_dealloc’:
./Modules/posixmodule.c:14198:26: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
14198 |     freefunc free_func = PyType_GetSlot(tp, Py_tp_free);
      |                          ^~~~~~~~~~~~~~
./Modules/posixmodule.c: At top level:
./Modules/posixmodule.c:14211:21: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
14211 |     {Py_tp_dealloc, ScandirIterator_dealloc},
      |                     ^~~~~~~~~~~~~~~~~~~~~~~
./Modules/posixmodule.c:14211:21: note: (near initialization for ‘ScandirIteratorType_slots[0].pfunc’)
./Modules/posixmodule.c:14212:22: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
14212 |     {Py_tp_finalize, ScandirIterator_finalize},
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~
./Modules/posixmodule.c:14212:22: note: (near initialization for ‘ScandirIteratorType_slots[1].pfunc’)
./Modules/posixmodule.c:14213:18: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
14213 |     {Py_tp_iter, PyObject_SelfIter},
      |                  ^~~~~~~~~~~~~~~~~
./Modules/posixmodule.c:14213:18: note: (near initialization for ‘ScandirIteratorType_slots[2].pfunc’)
./Modules/posixmodule.c:14214:22: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
14214 |     {Py_tp_iternext, ScandirIterator_iternext},
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~
./Modules/posixmodule.c:14214:22: note: (near initialization for ‘ScandirIteratorType_slots[3].pfunc’)
./Modules/posixmodule.c:15802:19: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
15802 |     {Py_mod_exec, posixmodule_exec},
      |                   ^~~~~~~~~~~~~~~~
./Modules/posixmodule.c:15802:19: note: (near initialization for ‘posixmodile_slots[0].value’)
make: *** [Makefile:2045: Modules/posixmodule.o] Error 1

odules/gcmodule.c:2034:19: note: (near initialization for ‘gcmodule_slots[0].value’)
gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall  -pedantic  -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration
 -fvisibility=hidden  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I./Include/internal -c ./Modules/posixmodule.c -o Modules/posixmodule.o
In file included from ./Include/Python.h:51,
                 from ./Modules/posixmodule.c:12:
./Modules/posixmodule.c:6838:11: error: array size missing in ‘os_sched_param__doc__’
 6838 | PyDoc_VAR(os_sched_param__doc__);

Python/ceval.c:1223:25: warning: ISO C forbids ‘goto *expr;’ [-Wpedantic]
 1223 | #define DISPATCH_GOTO() goto *opcode_targets[opcode]
      |                         ^~~~
Python/ceval.c:1236:9: note: in expansion of macro ‘DISPATCH_GOTO’
 1236 |         DISPATCH_GOTO(); \
      |         ^~~~~~~~~~~~~
Python/ceval.c:4205:13: note: in expansion of macro ‘DISPATCH’
 4205 |             DISPATCH();
      |             ^~~~~~~~
Python/ceval.c:1223:25: warning: ISO C forbids ‘goto *expr;’ [-Wpedantic]
 1223 | #define DISPATCH_GOTO() goto *opcode_targets[opcode]
      |                         ^~~~
Python/ceval.c:1236:9: note: in expansion of macro ‘DISPATCH_GOTO’
 1236 |         DISPATCH_GOTO(); \
      |         ^~~~~~~~~~~~~
Python/ceval.c:4252:13: note: in expansion of macro ‘DISPATCH’
 4252 |             DISPATCH();
msg398670 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-31 23:03
I'm removing the parser component, as this is a general problem (the only reason you see the parser is because with -Werror that is reported first).
msg398706 - (view) Author: Dennis Clarke (blastwave) Date: 2021-08-01 15:12
I very likely do not understand what is happening here. From my little
perspective the Python project has become far too critical to be yet
another language that can not be ported and used just about anywhere. I
often port software from various places into strange machines and even
onto z/OS mainframe type places. There is nothing more beautiful than
to take some C89 clean code and watch it just work. Flawlessly. Even the
OpenSSL project is locked neatly to that old C89 standard. I have tried
to get into a discussion about C99 but was always flatly told that we
need OpenSSL to work everywhere. Pretty much on anything that you can
get a compiler will do just fine. With the exception of some very small
embedded devices or tight memory constraints. It just works. Sadly the
Go Programming language is not like that. Neither is Rust. When I look
at The Python Project "Style Guide for C Code" here : 

    https://www.python.org/dev/peps/pep-0007/ 

The message is clearly stated :

    Python versions greater than or equal to 3.6 use C89 with 
    several select C99 features:

        - Standard integer types in <stdint.h> and <inttypes.h>.
            We require the fixed width integer types.

        - static inline functions

        - designated initializers (especially nice for type
                                                 declarations)

        - intermingled declarations

        - booleans

        - C++-style line comments

    Future C99 features may be added to this list in the future
    depending on compiler support (mostly significantly MSVC).

    Don't use GCC extensions (e.g. don't write multi-line strings
                                       without trailing backslashes).

    All function declarations and definitions must use full prototypes
         (i.e. specify the types of all arguments).

    Only use C++ style // one-line comments in Python 3.6 or later.

    No compiler warnings with major compilers (gcc, VC++, a few others).

That last line is a bit of a dream but I didn't write that. I merely 
took a copy from the "Style Guide for C Code".  So perhaps that needs a
rewrite and just state that the code will be mostly C99 safe and maybe
it would be best to just say iso9899:2011 and keep on plowing forwards.

One thing is certain, I built the OpenSSL 3.0.0 beta1 software on a pile
of systems in the last few weeks and then rebuilt a pile of dependant
libs and tools. They all work. Curl and libCurl is flawless. I am trying
to get Apache httpd 2.4.x ( and also trunk ) built and running. The only
major piece missing, critical and really important, is Python.  OKay I 
also have issues with ISC Bind but they seem to be drinking some strange
brew lately and their unit tests and other code has gone crab sideways.
That is another problem in someone elses backyard.  Python however looks
to be very highly portable and it just works on everything. Pretty much.

So having said all that should this just be iso9899:2011 with no major
surprises?

ps: from the "Style Guide for C Code" we also see these gems : 

        Use 4-space indents and no tabs at all.

        No line should be longer than 79 characters. If this and the
        previous rule together don't give you enough room to code, your
        code is too complicated -- consider using subroutines.

        No line should end in whitespace. If you think you need significant
        trailing whitespace, think again -- somebody's editor might delete
        it as a matter of routine.

Those are just priceless old rules from the Fortan punchcard days.
msg398709 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-08-01 15:44
I understand where you are coming from and I do agree, but this is something bigger than just what we can do in an issue, as it spawns multiple other places (again, many files fail with -pedantic). Is not a titanic task but is also not straightforward. My recommendation is to send a brief email to python-dev about these concerns to gather some feedback from the community, as this issue is probably not going to have all the attention that this would otherwise require.

For example, there are several pieces of infrastructure that use GNU extensions already by default when compiled with clang and gcc (like computed gotos), so activating -pedantic will invalidate those simple checks.
msg398710 - (view) Author: Dennis Clarke (blastwave) Date: 2021-08-01 15:53
Oh, I think we can give up on -pedantic and -pedantic-errors. It is
just a nifty litmus paper test to see how code cranks under nasty
contraints. I would be hapyp with iso9899:1999 or even iso9899:2011.

Thank you for the feedback and the excellent response time. I am so
very happy with the Python team bug report process and quite frankly
there are a lot of good people working on the quality code. 


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
History
Date User Action Args
2022-04-11 14:59:48adminsetgithub: 88952
2021-08-01 15:53:24blastwavesetmessages: + msg398710
2021-08-01 15:44:50pablogsalsetmessages: + msg398709
2021-08-01 15:12:03blastwavesetmessages: + msg398706
2021-07-31 23:05:29pablogsalsettitle: Code compliance concern in Parser/pegen/pegen.c -> CPython cannot be compiled with -pedantic
2021-07-31 23:03:55pablogsalsetmessages: + msg398670
2021-07-31 23:02:48pablogsalsetmessages: + msg398669
2021-07-31 22:59:16pablogsalsetmessages: + msg398668
2021-07-31 20:56:31blastwavesetmessages: + msg398664
components: + Parser, - C API
2021-07-31 20:55:18blastwavesetmessages: + msg398663
2021-07-31 12:19:11pablogsalsetmessages: + msg398635
2021-07-31 12:11:49blastwavesetmessages: + msg398634
components: - Parser
2021-07-31 01:25:53pablogsalsetmessages: + msg398616
2021-07-31 01:04:34Dennis Sweeneysetnosy: + Dennis Sweeney, pablogsal, lys.nikolaou
messages: + msg398614
components: + Parser
2021-07-30 23:47:48blastwavecreate