[Python-Dev] Assign to errno allowed? (original) (raw)

Brad Clements bkc@murkworks.com
Tue, 24 Sep 2002 15:31:23 -0400

On 24 Sep 2002 at 14:51, Guido van Rossum wrote:

I'm strongly against 2. 5 years from now, CE and NetWare and their limitations will only be a vague memory, but this convention will still cripple the Python source code.

No arguments about CE, anyway ..

(noting that NetWare has reached it's ten year anniversary ;-)

I guess then the best solution is a distinct CVS for "the port to oddball platforms"

or, the other option is lots of #ifdefs in the code.

The original reason I proposed the macro idea was to eliminate multiple nested #ifdefs..

For example, I had trouble figuring out nested #ifdefs in posixmodule, as generated by Mark in his CE port.. It's awful.

By switching to macros for "errno =" I was able to clean up a lot of the #ifdefs

If changes for CE (and other errno-less OS's) are to be kept in the core, then we'll either have (from Modules/cpickle.c)

#ifndef WINDOWCE errno = 0; #else SetLastError(0); #endif l = strtol(s, &endptr, 0);

#ifndef WINDOWSCE if (errno || (*endptr != '\n') || (endptr[1] != '\0')) { #else if (GetLastError() || (endptr != '\n') || (endptr[1] != '\0')) { #endif / Hm, maybe we've got something long. Let's try reading it as a Python long object. */ #ifndef WINDOWSCE errno = 0; #else SetLastError(0); #endif

--- Or ---

Py_SetErrno(0)
l = strtol(s, &endptr, 0);

if (Py_GetErrno() || (*endptr != '\n') || (endptr[1] != '\0')) {
    /* Hm, maybe we've got something long.  Let's try reading
       it as a Python long object. */
    Py_SetErrno(0);

Keeping in mind that adding NetWare or (other embedded OS or BIOS that wants to play) then the #ifdef version gets much worse. The macro version doesn't change.

There are approximately 140 references to errno in the Modules directory alone. For the Alpha port of Python 2.2 to CE I changed every one of them (at least for any module that could run on CE, which is just about everything that runs on Win32)

I've already said that I've made these changes and am willing to make them all again. Once they're in there, how difficult will it be to keep them?

New code that uses errno will fail on subsequent builds on these errno-less platforms, but there will only be a handful of changes needed, rather than hundreds on every release of the core.

So .. developers who just write "errno = " in the future won't be penalized, rather the porters to errno-less platforms will just have to convert the expression to macro mode.

And that conversion process isn't a hardship if it only has to be done once for any given line of code on any given core release.. But if we (porters) have to change 140 references every single time there's a release.. I could see enthusiasm fading away faster than those errno-less platforms ;-)

Clearly you guys know what's best better than I do. My line of reasoning for errno macros was:

  1. on most platforms the macros compile away to what you'd write in C anyway

  2. I'd generate and submit all the initial patches to the core to switch errno references to macros, leaving the burden of review and checkin to the core team (sorry) but not the burden of finding and changing all errno references

  3. But once the patches are in-place, future releases wouldn't require nearly as much effort for re-port's to errno-less platforms because only a few lines would need to be "fixed up" to use macros, and only if the changed code didn't use the macros in the first place.

  4. Not using the macros in core or extension source isn't an issue for any platform, except errno-less OS's.. at which time that code gets macro'ized at the time of the port.

  5. What this does is reduces effort for future ports to crippled systems, at the expense of many initial changes, whose subsequent maintenence shouldn't (hopefully) be a burden, since ports to crippled systems would maintain the changes.

Though I do agree, a future mismash of macro's and direct errno references in the core will be ugly and confusing if that occurs.

(sorry this is so long, just want to clearly state my case if I have not already done so)

Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax AOL-IM: BKClements