Trent Mick wrote:
>
> There is a subtlety in CreateProcess in the Win32 API in that if one
> specifies an environment (via the lpEnvironment argument), the
> environment strings (A) must be sorted alphabetically and (B) that sort
> must be case-insensitive. See the Remarks section on:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
>
>
> If this is not done, then surprises can happen with the use of
> {Get|Set}EnvironmentVariable in the created process:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getenvironmentvariable.asp
>
>
> Neither _subprocess.pyd (supporting the new subprocess.py module on
> Windows) nor PyWin32's CreateProcess binding do this. I haven't done so
> yet, but I should be able to put together a test case for subprocess.py
> for this. We came across such a surprise when using my process.py module
> that uses this PyWin32 code (which it looks like _subprocess.c borrowed).
>
> Fixing (A) is easy with a "PyList_Sort(keys)" and some other minor
> changes to _subprocess.c::getenvironment() -- and to
> win32process.i::CreateEnvironmentString() in PyWin32.
>
> However, I'd like some guidance on the best way to case-insensitively
> sort a Python list in C code to fix (B). The best thing I see would be
> to expose PyString_Lower/PyUnicode_Lower and/or
> PyString_Upper/PyUnicode_Upper so they can be used to .lower()/.upper()
> the given environment mapping keys for sorting.
>
> Does that sound reasonable? Is there some problem to this approach that
> anyone can see?
If you want to sort the list in C, it's better to provide
a C sorting function. That function can then use
Py_UNICODE_TOUPPER(ch) and toupper() for the comparison.
Calling the .upper() method on the object would be much
too expensive. Dito for creating new objects just for the
purpose of comparing two objects.
I think it would be worthwhile to consider replacing the
string implementation's direct usage of toupper(), tolower()
etc. with a Py_STRING_TOUPPER(ch) et al. approach much
like the Unicode object does - at least for consistency
reasons.
In the future, I think it would be best to move
away from the C lib implementation of toupper(), tolower()
et al. because these are affected by the current locale
settings which is not what you'd normally expect in
Python.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 27 2004)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
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