print statement and multithreading

[Thomas Wouters]

On Wed, Aug 30, 2000 at 11:29:08AM +0100, Paul Duffin wrote:

> All I wanted was the definitive reference to the definition of
> "Standard ANSI C" that was used when modifying the Python source
> and which is available in a form that I can read.

I probably shouldn't be replying, because I haven't read the entire thread,
but as one of the people who ANSIfied the Python source, I have to say this:
we (or at least, I) did not use a reference text to translate K&R C into
ANSI C. I just used 'common sense', which means I used the ANSI C knowledge
I already had, probably learned from Peter v/d Lindens' "Deep C Secrets" or
one of the less enjoyable C books I've read in the last 6 years.

The main difference is the function prototype and function definition. Also,
variable-args functions are handled differently. Both these things are
'sharp breaks' with K&R C: they're either ANSI C constructs, or K&R C, and
there is not much room for confusion. And because variable-args already
existed in 'two kinds' in the code, we only had to remove the old, K&R C,
kind. The same goes for, for example, the return value of signal().

I *think* we managed to avoid the *subtle* differences between ANSI C and
K&R C, like the result of mixing certain types of unsigned and signed
datatypes in certain ways. But these issues would have been detected long
ago, anyway, because most modern compilers don't make that big a difference
between ANSI C and K&R C, and will happily accept mixed code. And the
functions that ANSI C defines and K&R C does not (the ones Python uses,
anyway) were already being auto-detected by autoconf, and still are. We
could remove some of those checks, but in the mean time, they don't hurt.

Besides, it's still C. It's not like Python was ported to FORTRAN or
anything.
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!