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: C99 comments in Python 2.6 break build on AIX 6.1
Type: compile error Stage: resolved
Components: Interpreter Core Versions: Python 3.0, Python 3.1, Python 2.6
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: barry Nosy List: apaprocki, barry, christian.heimes, drj, georg.brandl, lemburg, pitrou, r.david.murray, terry.reedy
Priority: normal Keywords:

Created on 2008-10-03 08:15 by drj, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
py26aix61script1 drj, 2008-10-03 08:15 Full transcript
Messages (11)
msg74229 - (view) Author: David Jones (drj) * Date: 2008-10-03 08:15
Doing a plan "configure" then "make"; the compilation breaks due to // 
style comments in a file called Objects/frameobject.c:

cc_r -qlanglvl=extc89 -c  -DNDEBUG -O  -I. -IInclude -I./Include   -
DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c
"Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error.

Full transcript attached.

Furthermore, attempting to select a more permissive (better?) compiler, 
with "CC=c99 ./configure --without-gcc" for example, doesn't work 
because of the bug reported in http://bugs.python.org/issue1633863 (CC 
is ignored).  I will comment separately in that issue.

It is my understanding (per my blog article http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/ ) 
that the code is now c89 clean (or at least as clean as «gcc -std=c89 -
Werror» can make it.  That means you should be able to close this bug 
fairly quickly. :)

After I've hacked the configure script the build still fails, but for 
different reasons.  I'll file another bug for that.
msg74232 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-10-03 08:33
Christian, I guess it's all fixed now?
msg76799 - (view) Author: Andrew Paprocki (apaprocki) Date: 2008-12-02 22:57
summary of compiler errors/warnings i just hit in the same situation
with stock Python-2.6.tgz:

>>>>>>>>>>>>>> c++ style comment used
"Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error.
"Objects/unicodeobject.c", line 118.1: 1506-046 (S) Syntax error.
"Objects/unicodeobject.c", line 125.1: 1506-046 (S) Syntax error.
"Objects/unicodeobject.c", line 130.1: 1506-046 (S) Syntax error.
"Objects/unicodeobject.c", line 149.1: 1506-046 (S) Syntax error.
"Objects/unicodeobject.c", line 153.1: 1506-046 (S) Syntax error.
& a bunch of other places in unicodeobject.c
"Python/_warnings.c", line 380.19: 1506-046 (S) Syntax error.
"Python/_warnings.c", line 803.5: 1506-046 (S) Syntax error.

>>>>>>>>>>>>>> inline keyword was used
"./Modules/signalmodule.c", line 112.1: 1506-277 (S) Syntax error:
possible missing ';' or ','?

>>>>>>>>>>>>>> other warning
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for M is not valid. Type unsigned assumed.
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for N is not valid. Type unsigned assumed.
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for O is not valid. Type unsigned assumed.
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for P is not valid. Type unsigned assumed.
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for Q is not valid. Type unsigned assumed.
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for R is not valid. Type unsigned assumed.
"/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159
(E) Bit field type specified for S is not valid. Type unsigned assumed.
msg76803 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-12-02 23:43
There are still quite a few C99 comments left in the code, esp. in code
that's meant for MSVC (which works fine with them) and code for the Mac
(which uses gcc and also doesn't have problems with them). Esp. the
ctypes and libffi code is full of them.

FWIW, this one exists in both SVN trunk and the Python 3.0 branch:

./Modules/_ctypes/callproc.c:
--                         MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), //
Default language

Personally, I'd find it a lot better to not use C99 style comments in
code that's not specifically meant for a C++-capable compiler like MSVC.
msg76805 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-12-03 00:44
Barry, the issue in _ctypes/callproc.c could be a problem for us
although Python 2.6 and 3.0 are compiling fine with -std=c89. Should the
comment be fixed before the release?
msg76806 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2008-12-03 00:46
For 2.6.1, yes you can fix the comments if you can do it now :)
msg76822 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-12-03 10:20
On 2008-12-03 01:44, Christian Heimes wrote:
> Christian Heimes <lists@cheimes.de> added the comment:
> 
> Barry, the issue in _ctypes/callproc.c could be a problem for us
> although Python 2.6 and 3.0 are compiling fine with -std=c89. Should the
> comment be fixed before the release?

I had a second look at the code. That comment is in #ifdefs:

#ifdef MS_WIN32
...
#endif

so it won't affect compiling ctypes on Unix platforms.

Still, I find the situation with C99 comments scattered around the
source code less than ideal. Either we officially abandon C90 and move
on to C99 or we stick to C90 for all source code (including code that
only gets compiled on Macs or MSVC).

It's just too easy for a C99 comment to slip into code that's
targeted for non-gcc/non-MSVC compilers as well and these then
break the portability of Python to those compilers/platforms.
msg76833 - (view) Author: Andrew Paprocki (apaprocki) Date: 2008-12-03 17:22
The list of files/lines I posted yesterday was all that I had to change
to get it to build here (where a C++ style comment is a syntax error),
so it doesn't seem like a massive change.
msg79342 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-01-07 15:42
It seems everything has been fixed in the 2.6 branch and in trunk.
Andrew, can you do a quick SVN checkout and test it?
msg104544 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-04-29 17:48
In the absence of further complaints, this appears to really be fixed. Should it be closed as such?
msg104555 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-04-29 18:16
Sure.  It can always be reopened if the OP comes back and says it isn't fixed.  I'm closing it out of date because there are no references to checkins that fixed it.
History
Date User Action Args
2022-04-11 14:56:39adminsetgithub: 48275
2010-04-29 18:16:03r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg104555

resolution: out of date
stage: resolved
2010-04-29 17:48:34terry.reedysetstatus: pending -> open
nosy: + terry.reedy
messages: + msg104544

2009-01-07 15:42:40pitrousetnosy: + pitrou
messages: + msg79342
2008-12-03 17:22:36apaprockisetmessages: + msg76833
2008-12-03 10:20:03lemburgsetmessages: + msg76822
2008-12-03 00:46:43barrysetmessages: + msg76806
2008-12-03 00:44:27christian.heimessetassignee: christian.heimes -> barry
resolution: fixed -> (no value)
messages: + msg76805
nosy: + barry
2008-12-02 23:43:22lemburgsetnosy: + lemburg
messages: + msg76803
versions: + Python 3.0, Python 3.1
2008-12-02 22:57:13apaprockisetnosy: + apaprocki
messages: + msg76799
2008-10-03 08:33:56georg.brandlsetstatus: open -> pending
assignee: christian.heimes
resolution: fixed
messages: + msg74232
nosy: + christian.heimes, georg.brandl
2008-10-03 08:15:05drjcreate