[Python-Dev] C99

INADA Naoki songofacandy at gmail.com
Sat Aug 6 01:27:15 EDT 2016


I think these features may improve C code readability.
(Easy feature first).

* // one line comment

* inline function
static inline function can be used instead of may macros.
It is more readable, and type safe.

* Designated Initializers; { .key = value };
https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

Defining new type may be much shorter.

* stdint.h
https://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h

If we can relying to it, we can remove like PY_INT_32

* variadic macro

It may reduce some wrapper functions, but I'm not sure.


On Sat, Aug 6, 2016 at 1:04 PM, Guido van Rossum <guido at python.org> wrote:
> Different question. What features are we actually talking about? Is it
> possible to enumerate them?
>
> The only thing I'm aware of is declarations following non-declarations
> in the same block, but I'm no C expert any more.
>
> On Fri, Aug 5, 2016 at 8:43 PM, Ned Deily <nad at python.org> wrote:
>> On Aug 5, 2016, at 23:02, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> 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.
>>>
>>> It also gives us an objective criterion for when we change the
>>> definitions: when the baseline compiler version for the respective
>>> platform builds change, and Python 3.x versions using the older
>>> definition are no longer supported by python-dev.
>>>
>>> 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)
>>>
>>> The other question we need to consider is the possible impact on PEP
>>> 11: what happens to support for alternate compilers and platforms that
>>> *have* a buildbot, but may not support particular C99 features? Should
>>> there be a 4th clause that says "- must compile and run on all stable
>>> buildbots"?
>>
>> [Nick's reply above arrived just as I was getting ready to send my own response below which covers some of the same territory.]
>>
>> On Aug 5, 2016, at 18:37, Guido van Rossum <gvanrossum at gmail.com> wrote:
>>> I think if we want to revisit this in the future it should be an
>>> explicit change.
>>> On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon <brett at python.org> wrote:
>>>> On Fri, 5 Aug 2016 at 15:17 Guido van Rossum <gvanrossum at gmail.com> wrote:
>>>>> I want it to list specific versions that are known to be good right
>>>>> now, so we can point fingers appropriately when a regression happens.
>>>> OK, then we could pin it to MSVC 2016, gcc 6.1, and clang 3.8.1 which are
>>>> the latest releases (unless I'm missing a compiler we all feel like we
>>>> should officially support).
>>
>> While in principle allowing C99 features to be used in cpython is a *good* thing, I'm sure that I don't fully understand all of the implications of adopting this policy for 3.6.  I think we need to be sure we don't inadvertently drop support for some platforms and/or older releases of some platforms.  The key word is "inadvertently".  Not all of those compiler versions above are supported everywhere we currently run.  If that's what we want to do, that's fine but we should be explicit about that.  Two sets of concerns that come to mind are our buildbots and support for older OS X releases.
>>
>> If I gathered the data correctly, for the default branch (upcoming 3.6 release), we currently have 31 buildbots: 19 classified as "stable" and 12 as "unstable".  Of the stable buildbots, here is the count, version, and platform architecture of compilers in use:
>>
>> 2 x MSVC 14.0 2015 64 bit (AMD64)
>> 1 x MSVC 14.0 2015 32 bit (AMD64)
>>
>> 1 x Clang 3.8.0 (AMD64)
>> 1 x Clang 3.4.1 (AMD64)
>>
>> 1 x GCC 5.3.1 (s390x)
>> 2 x GCC 4.9.3 (x86)
>> 2 x GCC 4.9.2 (AMD64)
>> 1 x GCC 4.9.2 (PPC64LE)
>> 2 x GCC 4.8.5 (s390x)
>> 1 x GCC 4.8.4 (x86)
>> 1 x GCC 4.8.3 (PPC64)
>> 1 x GCC 4.3.3 (AMD64)
>> 2 x GCC 4.2.1 (AMD64)
>> 1 x GCC 4.0.1 (x86)
>>
>> I know very little about the details of C99 support in those compilers but I gather from this link (https://gcc.gnu.org/c99status.html) that GCC 4.5 is potentially the earliest level that properly supports C99.  Note that we have a number of buildbots running version of GCC older than 4.5 (including all of our OS X stable buildbots) and only one (an s390) running 5.x and none yet running 6.x.
>>
>> I don't know that we've written this policy anywhere but I think it has been our de facto policy to require only the "standard" platform build tools (including compilers) to build or install Python on our supported platform versions.  With my OS X hat on, I know this likely presents an issue for the OS X installer builds.  Up to now, we have been providing installers that run on all Macs that are supported back to at least OS X 10.6 and, to do that, we build on 10.6 with the standard Apple build tools available there including GCC 4.2.  If GCC 4.2 proves to no longer be suitable, we'll have to make some adjustment in either what versions of OS X we support and/or how we build python.org Pythons for OS X.  There are several possibilities, and, at some point, we will need to do something anyway.  I am hoping to propose and implement some changes prior to 3.6.0b1 and this discussion will shape that proposal.
>>
>> I don't think OS X support should be a gating factor in deciding to move ahead with C99 adoption but it does point out that there might be more ramifications to this decision.  What may be more difficult is to judge the impact on other platforms that don't get as much attention from most of us.  For this to move forward, we need to be able to state what the impact to current users will be.
>>
>> --
>>   Ned Deily
>>   nad at python.org -- []
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com



-- 
INADA Naoki  <songofacandy at gmail.com>


More information about the Python-Dev mailing list