GitLab

supposed to be declared in system include files (with a proper prototype.)
Should be moved to a platform-specific block if anyone finds out which
broken platforms need it :-)

    a glibc, not a gcc, problem.

This should not be used for new code, but will probably make porting
old extensions to 2.0 a lot easier.

Also see Bug #116011.

#define'd to an unreasonable value (several recent gcc systems have
misdefined it, causing bogus overflows in integer multiplication).  Nuke
CHAR_BIT entirely.

Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.

This closes SourceForge patch #101659 and bug #115323.

It's hard to sort out what the bug was, exactly.  So, Big Hammer:

1. Python shouldn't be in the business of #define'ing NULL, period.
2. Users of the Python C API shouldn't be in the business of not including
   Python.h, period.

Hence:

1. Removed all #define's of NULL in Python source code (pyport.h and
   object.h).
2. Since we're *relying* on stdio.h defining NULL, put an #error in
   Python.h after its #include of stdio.h if NULL isn't defined then.

(sources) which may still use it and now fail to compile.
Reported by M-A Lemburg.  Closes [ Bug #113576 ].

This should match the situation in the 1.6b1 tree.

by the following.

typedef in a portable way the Python name for the C9X uintptr_t type.
This latter is the most portable way to spell an integral type to
which a void* can be cast to and back again without losing
information.  Parallel checkin hacks configure to check if the
platform/compiler supports the C9X name.

This was a misleading bug -- the true "bug" was that hash(x) gave an error
return when x is an infinity.  Fixed that.  Added new Py_IS_INFINITY macro to
pyport.h.  Rearranged code to reduce growing duplication in hashing of float and
complex numbers, pushing Trent's earlier stab at that to a logical conclusion.
Fixed exceedingly rare bug where hashing of floats could return -1 even if there
wasn't an error (didn't waste time trying to construct a test case, it was simply
obvious from the code that it *could* happen).  Improved complex hash so that
hash(complex(x, y)) doesn't systematically equal hash(complex(y, x)) anymore.

standard C++ specific includes.

Closes patch 101061.

(and yes, "Currintly" also counts <0.5 wink>)

marked my*.h as obsolete

for systems that are missing those declarations from system include files.
Start by moving a pointy-haired ones from their previous locations to the
new section.

(The gethostname() one, for instance, breaks on several systems, because
some define it as (char *, size_t) and some as (char *, int).)

I purposely decided not to include the summary of used #defines like Tim did
in the first section of pyport.h. In my opinion, the number of #defines
likedly to be used by this section would make such an overview unwieldy. I
would suggest documenting the non-obvious ones, though.

handlers "return void", according to ANSI C.
Removed the new Py_RETURN_FROM_SIGNAL_HANDLER macro.
Left RETSIGTYPE in the config stuff, because it's not clear to
me that others aren't relying on it (e.g., extension modules).

good C practice hasn't been available to everything all along.
Added Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) macro to pyport.h; this
just casts VALUE from type WIDE to type NARROW, but assert-fails if
Py_DEBUG is defined and info is lost due to casting.
Replaced a line in Fredrik's fix to marshal.c to use the new macro.

    #if RETSIGTYPE != void
That isn't C, and MSVC properly refuses to compile it.
Introduced new Py_RETURN_FROM_SIGNAL_HANDLER macro in pyport.h
to expand to the correct thing based on RETSIGTYPE.  However,
only void is ANSI!  Do we still have platforms that return int?
The Unix config mess appears to #define RETSIGTYPE by magic
without being asked to, so I assume it's "a problem" across
Unices still.

(cf. the rest of the headers in the distribution)

This was a convenient excuse to create the pyport.h file recently
discussed!
Please use new Py_ARITHMETIC_RIGHT_SHIFT when right-shifting a
signed int and you *need* sign-extension.  This is #define'd in
pyport.h, keying off new config symbol SIGNED_RIGHT_SHIFT_ZERO_FILLS.
If you're running on a platform that needs that symbol #define'd,
the std tests never would have worked for you (in particular,
at least test_long would have failed).
The autoconfig stuff got added to Python after my Unix days, so
I don't know how that works.  Would someone please look into doing
& testing an auto-config of the SIGNED_RIGHT_SHIFT_ZERO_FILLS
symbol?  It needs to be defined if & only if, e.g., (-1) >> 3 is
not -1.