I've let this lie for a few days to see whether any other comments were
forthcoming, but nothing's turned up...
On 27 Jan 2002, Martin v. Loewis wrote:
> 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).
Fair enough. I was trying to minimise stylistic differences in the fix,
but if using _Py_getname is the canonical solution, that's easy fixed.
> > - 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.
I did it the way I did because there's already code dealing with other
brokeness in this area which doesn't solve the EMX issue, and the #ifdef
solution minimises the risk of EMX fixes breaking something else which I
can't test. At this stage I can't see this bug being fixed in EMX :-(
> 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.
Definitely a more general approach, which I'll look at in detail.
> 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.
While there are sh/bash shells for OS/2, they're not standard equipment.
Autoconf also has a very spotty record on OS/2, although there are people
trying to improve that.
> > 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?
The last I heard, Guido expected I was going to commit my own patches
(after review), so I was allowing time for my initial attempts to commit
to be checked by regular builders/testers of the tree before getting to
changes that affect non-EMX specific parts of Python.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370
andymac@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4