(previously submitted to comp.lang.python) 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 Paul Sheer . . . . . . . . . . . . . . . . . Tel . . +27 (0)21 6869634 Email . . . http://2038bug.com/email.gif . . . . . . . . . . . . . . . . http://www.icon.co.za/~psheer . . . . . . . . . http://rute.2038bug.com L I N U X . . . . . . . . . . . . . . . . The Choice of a GNU Generation