[Python-Dev] Assign to errno allowed?

[Brad Clements]

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