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

John Machin machin_john_888 at hotmail.com
Thu May 24 22:31:49 EDT 2001


"Alex Martelli" <aleaxit at yahoo.com> wrote in message news:<9eiq9j0tcn at enews1.newsguy.com>...
> "John Machin" <machin_john_888 at hotmail.com> wrote in message
> news:92ae279c.0105231432.7aab5dde at posting.google.com...
>     ...
> > [snip]
> > > ::: bill.c
>  [snip]
> > >     if(!value) { // deletion
> >
> > C? Portable?
> 
> Sure, any C compiler compliant with the current standard
> (aka C-99) should have no problem with this construct!-).
> 
> I don't have a C-99-compliant compiler around, but all
> of my compilers do support a subset of the standard, so,
> why not use it?-)
> 
> Of course, if you do desire the "anywhere" I put in my
> subject you'd better backport to some older standard
> such as C-89 or K&R, and use /* ... */ for comments:-).
> 
> In fact, I used // for comments even in the "Win32 API
> in C" tutorial I placed on the net -- if there's one
> piece of syntax sugar I can't stand is comments that
> are not terminated by end-of-line.  I applaud the C
> Standardization Committee for including //...!

I agree with Alex on this last point. Also the compilers that I use
support
// for comments. However the issue is portability.

I don't purport to be an expert on portability of C code; I'd just
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
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.

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
"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!!



More information about the Python-list mailing list