[Python-Dev] updated patches for OS/2 EMX port

Martin v. Loewis martin@v.loewis.de
27 Jan 2002 21:32:44 +0100


Andrew MacIntyre <andymac@bullseye.apana.org.au> writes:

> - Modules/unicodedata.c is affected by a name clash between the internally
> defined _getname() and an EMX routine of the same name defined in
> <stdlib.h>.  The patch renames the internal routine to _getucname() to
> avoid this, but this change may not be acceptable - advice please.

My advice for renaming things because of name clashes: Always rename
in a way that solves this particular problem for good, by using the Py
prefix (or _Py to further indicate that this is not public API; it's a
static function, anyway). Somebody may have a function _getucname
somewhere, whereas it is really unlikely that people add a Py prefix
to their functions (if they have been following the last 30 years of C
programming).

> - Objects/stringobject.c and Objects/unicodeobject.c contain changes to
> handle the EMX runtime library returning "0x" as the prefix for output
> formatted with a "%X" format.

I'd suggest a different approach here, which does not use #ifdefs:
Instead of testing for the system, test for the bug. Then, if the bug
goes away, or appears on other systems as well, the code will be good.

Once formatting is complete, see whether it put in the right letter,
and fix that in the result buffer if the native sprintf got it wrong.

If you follow this strategy, you should still add a comment indicating
that this was added for OS/2, to give people an idea where that came
from.

Another approach would be to autoconfiscate this particular issue. I'm
in general in favour of autoconf'ed bug tests instead of runtime bug
tests, but people on systems without /bin/sh might feel differently.

> If there are no unresolvable objections, and approval to apply these
> patches is granted, I propose that the patches be applied as follows:-
> 
> Stage 1:  the build patch (creates+populates PC/os2emx/)
> Stage 2:  the Lib/plat-os2emx/ patch
> Stage 3:  the Lib/ and Lib/test/ patches
> Stage 4:  the distutils patch
> Stage 5:  the Include/, Objects/ and Python/ patches
> Stage 6:  the Modules/ patch
> 
> I would expect to allow at least 48 hours between stages.
> 
> Comments/advice on this proposal also appreciated.

Sounds good to me (although I'd probably process the "uncritical",
i.e. truly platform-specific parts much more quickly). Who's going to
work with Andrew to integrate this stuff?

Regards,
Martin