Issue44789
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.
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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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:48 | admin | set | github: 88952 |
2021-08-01 15:53:24 | blastwave | set | messages: + msg398710 |
2021-08-01 15:44:50 | pablogsal | set | messages: + msg398709 |
2021-08-01 15:12:03 | blastwave | set | messages: + msg398706 |
2021-07-31 23:05:29 | pablogsal | set | title: Code compliance concern in Parser/pegen/pegen.c -> CPython cannot be compiled with -pedantic |
2021-07-31 23:03:55 | pablogsal | set | messages: + msg398670 |
2021-07-31 23:02:48 | pablogsal | set | messages: + msg398669 |
2021-07-31 22:59:16 | pablogsal | set | messages: + msg398668 |
2021-07-31 20:56:31 | blastwave | set | messages:
+ msg398664 components: + Parser, - C API |
2021-07-31 20:55:18 | blastwave | set | messages: + msg398663 |
2021-07-31 12:19:11 | pablogsal | set | messages: + msg398635 |
2021-07-31 12:11:49 | blastwave | set | messages:
+ msg398634 components: - Parser |
2021-07-31 01:25:53 | pablogsal | set | messages: + msg398616 |
2021-07-31 01:04:34 | Dennis Sweeney | set | nosy:
+ Dennis Sweeney, pablogsal, lys.nikolaou messages: + msg398614 components: + Parser |
2021-07-30 23:47:48 | blastwave | create |