[Python-Dev] C99

[Nathaniel Smith]

On Fri, Aug 5, 2016 at 8:02 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 6 August 2016 at 12:15, Steve Dower <steve.dower at python.org> wrote:
>> FYI, it's MSVC 14.0 (which is included in VS 2015).
>>
>> Personally I'd like to see it restricted to the common subset of C99 and
>> some version of C++ (which is obviously mostly C and includes no C++),
>> because I know there are a few things in C99 only that are very obscure
>> because they aren't also in C++.
>
> As a pragmatic requirement, what if we went with:
>
> - must compile with the Python 3.5 Windows compiler (so MSVC 14.0)
> - must compile with the Python 3.5 Mac OS X compiler (some version of clang?)
> - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
>
> The reason I like the pragmatic definition is that it's one we can
> readily automate by ensuring these 3 configurations are always present
> in the stable buildbot fleet, while the formal standards based version
> is technically more precise, but not in a way we can easily test.

This approach makes a lot of sense to me. In particular it seems like
it can avoid getting bogged down in a lot of questions about the
theoretical idea of C99, which is often somewhat unclear.

I wrote a little test file for all the C99 features that were
mentioned in this thread (I think):
  https://gist.github.com/njsmith/f666671de31f35644bb91a815c9cad75

Ned reports that our OS X compiler is currently GCC 4.2, and that this
doesn't officially support "C99" -- but I just checked and it happily
builds that file :-). (Judging from [1], it looks like the major
feature missing in 4.2 was support for C99's more obscure inlining
semantics; but I think we only really care about 'static inline'
specifically, and that appears to be unchanged [2].)

> Phrasing the policy that way would mean moving future iterations of
> the manylinux spec out of distutils-sig only territory into one which
> needs to be reviewed by both distutils-sig and python-dev (since it
> would now also modify CPython's compiler compatibility requirements in
> PEP 7), but I think that's a reasonable position to adopt, and
> unlikely to cause any major problems (manylinux is a *trailing* edge
> definition that is only likely to get updated as the oldest enterprise
> Linux definitions drop out of commercial support)

With my manylinux maintainer hat on, I don't think there'd be any
problem with bringing python-dev into those discussions.

But note that technically, the manylinux1 spec doesn't say what
compiler you can use; it says that whatever compiler you use has to
generate binaries that work on CentOS 5. (Why CentOS 5? Because it's
the oldest non-EOL linux distribution in common use; manylinux2 will
presumably bump the requirement to CentOS 6 once CentOS 5 goes EOL).

The reason this matters is that the official vendor compiler on RHEL 5
is gcc 4.1, but there's also a separately-distributed version of gcc
4.8.2 that can target it. If a packager trying to build manylinux
wheels wants a more modern gcc, then it's reasonable to ask them to
get this patched gcc. But for an end-user who's just trying to build
CPython on their machine, you might or might not consider this an
acceptable request -- maybe CPython wants to work on default vendor
compiler to imposing that on users.

And in practice this almost certainly doesn't matter -- the only
reason people jump through hoops to get gcc 4.8 is for its improved
C++ support. I just tried my c99 test file on CentOS 5's default gcc
4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for
3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4,
which is even less of a worry.

tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4"
should be a fine rule that works for everyone. But I guess we probably
also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.

-n

[1] https://gcc.gnu.org/c99status.html
[2] "The [different versions] of inlining behave similarly ... when
the inline keyword is used on a static function" --
https://gcc.gnu.org/onlinedocs/gcc/Inline.html

-- 
Nathaniel J. Smith -- https://vorpus.org