Compiling the Python sources with a C++ compiler (aCC)

[Paul Sheer]

I have managed to build Python 2.3.3 with the aCC HP-UX C++
compiler by making a number of one-line changes. (For reasons
beyond my control, I am forced to use this compiler and it has
no C mode at all.)

Typically to get the Python source code to compile under
aCC one has to make a number of trivial changes of the form,

     struct whatzit *p;
-    p = malloc (sizeof (struct whatzit));
+    p = (struct whatzit *) malloc (sizeof (struct whatzit));

since aCC has stricter casting rules than ANSI C and does
not automatically cast  void * .

Another change is where a forward declaration is
needed for the module type. The aCC compiler complines
about a duplicate definition. I change these from "static"
to "extern" which gives a warning, but otherwise works.
For example,

  + #define staticforward ... /* in my case 'extern' */

  - static PyTypeObject Comptype;
  + staticforward PyTypeObject Comptype;

(There is/was a staticforward macro which is not used
consistently.)

A third change are the Python module initializers
(PyMODINIT_FUNC xxx(void) {...): they need to obviously
be declared 'extern "C"' (for dl importing) which can
happen in the PyMODINIT_FUNC macro. However the macro
is not used consistently throughout the Python sources.

Finally, of course there are numerous uses of "new",
"class" and other C++ keywords. I wrote a short flex
script to search and replace through the entire sources
for instances of these.

To summarize the changes needed:

  1. explicit casting of void *
  2. consistant use of a "staticforward" type
     for PyTypeObject forward declarations.
  3. consinstant use of PyMODINIT_FUNC.
  4. use of PyMODINIT_FUNC even in prototypes
     (like config.c.in)
  5. renaming of C++ reserved words.

(There are other changes specific to the HP-UX
architecture - too numerous to mention.)

My question is: are the Python maintainers interested
in such compatibility?

Although Python will always be strict ANSI C, are such
changes not of general interest for the purposes of
consistency of the source code?

Can someone forward this email to the appropriate
developers list (or tell me which one)?

Shall I prepare a proper patch against 2.3.4?

What would the consensus be on replacements for
'new', 'class', 'template', 'operator', etc.?
Perhaps __new, zew, or new2; klass, __class, or
cla55 etc.?

Has this issue come up before? URLs?

Many thanks, best wishes

-paul