homepage

I don't know if the Python source is supposed to be compilable with a C++
compiler or not, but I'm having trouble finding a C compiler on the
Solaris10/SPARC machines at work. I decided to give a C++ compiler a whirl:
 /opt/gnu/bin/c++ -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I../Include -DPy_BUILD_CORE -o Parser/tokenizer.o ../Parser/tokenizer.c
 ../Parser/tokenizer.c: In function `char * PyTokenizer_RestoreEncoding(tok_state *, int, int *)':
 ../Parser/tokenizer.c:1614: ANSI C++ forbids implicit conversion from `void *' in assignment
Now this turns out to be a very old compiler:
 % /opt/gnu/bin/c++ --version
 2.95.3
Should Python be able to compile with this ancient GNU C++ compiler?
Thx,
Skip

Python should be compile-able with a C++ compiler. I'll test it on my
system in a couple of minutes.

The trunk contains lots of implicit casts from void pointers that make
the code incompatible with C++.

I disagree. It's not a requirement that the Python source code is
compilable as C++. Only the header files should be thus compilable.

Ah, I was under the impression that Python must be compatible both C++
and C89 compilers.
Do we have any means to test the C++ compatibility of the header files?
Full C++ compatibility is one way to make sure the header files are
compatible, too. *wink* I don't see harm in sprinkling explicit type
casts over the C code, too.

> Do we have any means to test the C++ compatibility of the header files?
No, we fix it when users report bugs (which typically happens very
quickly after we made some).
> Full C++ compatibility is one way to make sure the header files are
> compatible, too. *wink* I don't see harm in sprinkling explicit type
> casts over the C code, too.
That requires discussion, I'm opposed to such a change: it adds
unnecessary complication. In any case, such discussion would belong
to python-dev.

Closing as "won't fix" for now.