Standards for C source in extensions (was Re: extending Python with C anywhere (was Re: Extending Python with C/C++ on a win32 platform))

[Alex Martelli]

"John Machin" <machin_john_888 at hotmail.com> wrote in message
news:92ae279c.0105241831.70e9ca19 at posting.google.com...
    ...
> I don't purport to be an expert on portability of C code; I'd just

I used to [HAVE to] be, back about 8-10 years ago when we
supported a zillion different incompatible platforms (most
Unix dialects you can think of, MS stuff, VMS, Apollo, ...)
AND we used the native compiler on every platform.  I knew
my Harbison & Steele by heart, had my checklists of known
issues, etc.  The fact that we also had a lot of Fortran
sources needing to interoperate with the C parts made it
real 'fun', for some definition of 'fun'.

Then the non-Unix, non-MS platforms withered away (in terms
of our customer base) -- AND I finally managed to convince
our mgmt to switch to just gcc (for all Unixoid platforms)
plus MS C on MS platforms.  Suddenly my "C portability" work
load dropped dramatically, particularly as we migrated all
sources away from Fortran (f2c be thrice blessed... though
I had to tweak it a lot...).  [Things got 'fun' again soon,
thanks to the explosion of incompatible _C++_ dialects, but
that's another issue:-)].


> like to point out that there are niches out there that grok not gcc,
> and that the Python 2.1 source (at least as far as I looked (in
> objects and modules directories)) has no usage of // as a comment
> introducer. So I prefer to be conservative and not use constructs like
> // and variable-size arrays and other new (post C89) goodies in code
> that I might need or want to make widely available. That way I know

Absolutely -- Python is very clean and conservative ISO-C of
the C-89 persuasion, and this is exactly as it should be.

> that if Python exists for the platform then my stuff has a good chance
> of being compiled on that platform without back-porting or major
> surgery.

Nolo contendere.  I tried to keep exactly this philosophy when
doing gmpy, for example, because of the "widely available" issue.

Mostly, what I truly care about is that the extensions run on
'MY' platforms (MS OS's with MS C/C++, Unix-oid with gcc), so
I have fewer worries (and actually use Boost Python and C++,
most of the time -- my productivity's just too much higher
with those wrt spending my time debugging reference counts:-).


> Alex's comment about back-porting to K&R is not so funny -- please
> contemplate the scenario of a customer running HP-UX where the

Oh, I well recall HP-UX (used to be an absolutely key platform
for us), and NOT with rose-tinted nostalgia, believe me:-).

> "bundled" cc is actually K&R and they haven't thought it
> cost-effective to pay for the C89 compiler and awk is too slow for the
> job which is emergency format conversion of some seriously large files
> and no they don't have Python nor gcc ["Can't be any good if they are
> free" -- I'm working on it!] and Python would be no faster anyway and
> there's no other machine with a C89 compiler within time/distance
> constraints ... aarrgghh!!

...so you end up programming the emergency format conversion in
K&R C?  No chance to download and use a pre-built gcc for HP-UX,
a trial version of KAI C++, etc...?  Eeep.  Hope you get to charge
them dearly for their machine's misconfiguration, at least!-)


Alex