[0/5] CodingGuidelines: various C99 updates

Message

Ævar Arnfjörð Bjarmason Oct. 7, 2022, 9:30 a.m. UTC

This series:

 * Rephrases CodingGuidelines so that we note we're on C99, and then
   lists exceptions and features we use. The previous prose assumed
   C89 by default.

   We still explicitly avoid opening the "feel free to use an C99
   feature" floodgates.

 * Mentions that you can use dynamic C99 initializer elements. See the
   recent discussion at
   https://lore.kernel.org/git/[e-mail]/

 * Allows us to use "for (int i". I didn't set out to (slightly) jump
   the gun on this, but just pulling the trigger around ~20 days early
   makes it easier to ...

 * ...add the natural follow-up section of C99 features you explicitly
   shouldn't be using yet, to which I added the two cases I could
   remember (in 4-5/5).

Ævar Arnfjörð Bjarmason (5):
  CodingGuidelines: update for C99
  CodingGuidelines: mention dynamic C99 initializer elements
  CodingGuidelines: allow declaring variables in for loops
  CodingGuidelines: mention C99 features we can't use
  CodingGuidelines: recommend against unportable C99 struct syntax

 Documentation/CodingGuidelines | 34 ++++++++++++++++++++++++----------
 revision.c                     |  7 -------
 t/helper/test-parse-options.c  |  3 +--
 3 files changed, 25 insertions(+), 19 deletions(-)

Comments

Junio C Hamano Oct. 7, 2022, 5:54 p.m. UTC | #1

Ævar Arnfjörð Bjarmason  <[e-mail]> writes:

> This series:
>
>  * Rephrases CodingGuidelines so that we note we're on C99, and then
>    lists exceptions and features we use. The previous prose assumed
>    C89 by default.
>
>    We still explicitly avoid opening the "feel free to use an C99
>    feature" floodgates.

The above contradicts with each other.  A sensible position to
support the "we do not open the floodgate" is that when in doubt
stick to C89 but use C99 features that are explicitly allowed.

>  * Mentions that you can use dynamic C99 initializer elements. See the
>    recent discussion at
>    https://lore.kernel.org/git/[e-mail]/

Good.

>  * Allows us to use "for (int i". I didn't set out to (slightly) jump
>    the gun on this, but just pulling the trigger around ~20 days early
>    makes it easier to ...

This is a welcome change.  As anything this set of patches won't
become reality in any released version until mid December anyway,
this is the cycle to "revisit around November 2022".

>  * ...add the natural follow-up section of C99 features you explicitly
>    shouldn't be using yet, to which I added the two cases I could
>    remember (in 4-5/5).

And we do not have to say we do not use these from C99 if our base
is C89, with explicitly allowed features from C99.

Junio C Hamano Oct. 7, 2022, 6:15 p.m. UTC | #2

Junio C Hamano <[e-mail]> writes:

> Ævar Arnfjörð Bjarmason  <[e-mail]> writes:
>
>> This series:
>>
>>  * Rephrases CodingGuidelines so that we note we're on C99, and then
>>    lists exceptions and features we use. The previous prose assumed
>>    C89 by default.
>>
>>    We still explicitly avoid opening the "feel free to use an C99
>>    feature" floodgates.
>
> The above contradicts with each other.  A sensible position to
> support the "we do not open the floodgate" is that when in doubt
> stick to C89 but use C99 features that are explicitly allowed.

Ah, I think I misread the intention, which 1/5 clarified.  I think
"even though we require your CC claim to support C99, you are
expected to stick to C89 plus those features that are explicitly
allowed" is a very sensible thing to day.