[Python-Dev] C99 code in the Python core? (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Sat Jul 5 12:46:53 CEST 2008
- Previous message: [Python-Dev] C99 code in the Python core?
- Next message: [Python-Dev] bytearray and array.array are not thread-safe
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
(1) When is it okay to use C99 code in the Python core? More particularly, is it considered acceptable to use widely-implemented library functions that are specified in C99 but not ANSI C, or widely-implemented features that are new to C99?
[C99 is also ANSI C, IIUC. ANSI has adopted ISO/IEC 9899:1999 as a U.S. national standard.]
It's ok to use functions of the C99 standard library if you have a configure test and a fall-back implementation, or if you know that the function is available on all systems we care about.
Or is C99 code now acceptable pretty much anywhere?
No. As others have pointed out, Microsoft still hasn't implemented in Visual C.
If so, should PEP 7 be updated? It currently says: """Use ANSI/ISO standard C (the 1989 version of the standard)."""
No.
(2) Is it okay to use the '%a' format specifier for sprintf, sscanf and friends. Are there major platforms where this isn't implemented? (Using '%a' would make the issue implementation much simpler.)
It's implemented in VS 2008, see
http://msdn.microsoft.com/en-us/library/hf4y5e3w.aspx
On the other hand, people still might try to run Python on older versions of Solaris, such as Solaris 2.6 (which was released 1997). I don't know when Solaris' CRT first started to support this.
I'd add a configure test, and, at run-time, raise an exception if the C library doesn't support it yet somebody tries to use it.
Regards, Martin
- Previous message: [Python-Dev] C99 code in the Python core?
- Next message: [Python-Dev] bytearray and array.array are not thread-safe
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]