This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Jeffrey.Armstrong
Recipients Jeffrey.Armstrong
Date 2014-02-11.13:03:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1392123816.37.0.457546149708.issue20596@psf.upfronthosting.co.za>
In-reply-to
Content
In two locations, the current interpreter code makes some assumptions concerning the syntax of the wcstok() function based solely on the operating system (Windows, in this case).  Compilers other than MSVC may (and do) provide alternative wcstok() syntaxes.

The first change in the attached patch changes a preprocessor check in Modules/main.c to determine if we're compiling with MSVC rather than just whether we're compiling with Windows.  If so, it uses Windows's basic two-argument wcstok() function as it always has.  If the compiler isn't MSVC, the code will now default to the Unix method of converting to ASCII first before tokenizing.  This change is more sensible because the code should really be checking for the compiler's wcstok() capabilities, not what operating system Python is being compiled for.

The second change in the attached patch adds some new code to PC/getpathp.c to support alternate wcstok() syntax in the find_env_config_value() function.  A preprocessor check will now determine if we're compiling for MSVC and, if so, default to the three-argument wcstok_s() function.  If the almost-compatible Open Watcom compiler is detected, a three-argument, POSIX-like wcstok() function is used.  If another compiler is detected, the original two-argument wcstok() is assumed to be adequate.
History
Date User Action Args
2014-02-11 13:03:36Jeffrey.Armstrongsetrecipients: + Jeffrey.Armstrong
2014-02-11 13:03:36Jeffrey.Armstrongsetmessageid: <1392123816.37.0.457546149708.issue20596@psf.upfronthosting.co.za>
2014-02-11 13:03:36Jeffrey.Armstronglinkissue20596 messages
2014-02-11 13:03:35Jeffrey.Armstrongcreate