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

P

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
 
M

Michael Geary

Paul said:
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.)

Nice work! It seems like a good idea to me for Python to be compilable in
either C or C++ mode (not to mention it being a necessity in your case).
struct whatzit *p;
- p = malloc (sizeof (struct whatzit));
+ p = (struct whatzit *) malloc (sizeof (struct whatzit));

If that pattern is used a lot, it would be cleaner to use a macro and avoid
the duplication.

Untested, but ought to work:

#define malloc_struct( s ) ( (struct s*)malloc( sizeof(struct s) ) )

struct whatzit* p;
p = malloc_struct( whatzit );

-Mike
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Paul said:
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.)

Did you try to invoke c89(1)?

Regards,
Martin
 
P

Paul Sheer

If that pattern is used a lot, it would be cleaner to use a macro and avoid
the duplication.

there are many other pointer casts that are missing. malloc is only one.

-paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top