git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Carlo Arenas <carenas@gmail.com>
Subject: Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support
Date: Tue, 16 Nov 2021 13:54:27 +0100	[thread overview]
Message-ID: <211116.86pmr0p82k.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <YZOh370ZMMqSADUE@coredump.intra.peff.net>


On Tue, Nov 16 2021, Jeff King wrote:

> On Tue, Nov 16, 2021 at 02:12:41AM +0000, brian m. carlson wrote:
[...]
>> diff --git a/Makefile b/Makefile
>> index 12be39ac49..893d533d22 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1204,7 +1204,7 @@ endif
>>  # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
>>  # tweaked by config.* below as well as the command-line, both of
>>  # which'll override these defaults.
>> -CFLAGS = -g -O2 -Wall
>> +CFLAGS = -g -O2 -Wall -std=gnu99
>>  LDFLAGS =
>>  CC_LD_DYNPATH = -Wl,-rpath,
>>  BASIC_CFLAGS = -I.
>
> Do most compilers understand -std=gnu99? It seems like we're breaking
> the out-of-the-box build for everything that isn't gcc or clang.
>
> I understand that older versions of gcc (prior to 5.1.0, from my
> digging) default to gnu89, and so they would be broken _without_ this.
> So it is a tradeoff one way or the other. But somehow this seems
> backwards to me. We should assume that modern compilers support C99 out
> of the box, and put the burden on older ones to trigger C99 support in
> whatever non-portable way they need.
>
> I also checked clang, and it looks like it has defaulted to gnu11 since
> clang-7 (I'm not sure about clang-6; its documentation wasn't clear).

Yes, this seems like something we'd really want to feed to
"detect-compiler" after extracting it out of config.mak.dev.

And as you note it's not only that older or non-gcc non-clang compilers
may not understand this at all, but are we getting worse behavior on
modern versions of those two because they're forced into some 20 year
old C99 standard mode, instead of the current preferred default?

If we do go for this there's also the additional breakage I mentioned
upthread of th [1], and which I think I wasn't clear enough about. I.e. if we do:

    CFLAGS = -O2 -g -std=whatever

And then in config.mak.uname do e.g.:

    CFLAGS = -g -O0 -Winline

We'll override the -std=whatever, but just wanted to overrride the -O2.

This came up in another context recently (Carlo had series to hack in
this area), but I think we shouldn't add anything new to CFLAGS. Let's
instead add a new variable like BASIC_CFLAGS, so in this case
CFLAGS_C_STANDARD or whatever, and then later in the file:

    -ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS)
    +ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_C_STANDARD)

But IMO this whole thing of trying to make this work on every compiler
etc. just isn't worth it.

Let's just start using C99 features, and if anyone's compiler breaks on
something like CentOS 6 document that they'll need to tweak a flag
somewhere. We already know that works for all the other C99 features we
have, there seems to just be this one exception of the ancient GCC
version in this particular case.

1. https://lore.kernel.org/git/YZG9wF56unj7eYhl@camp.crustytoothpaste.net/

  reply	other threads:[~2021-11-16 13:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-14 21:24 [PATCH 0/1] Add a test balloon for C99 brian m. carlson
2021-11-14 21:24 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 support brian m. carlson
2021-11-15  1:14   ` Ævar Arnfjörð Bjarmason
2021-11-15  1:54     ` brian m. carlson
2021-11-15  3:16   ` Eric Sunshine
2021-11-16  1:53     ` brian m. carlson
2021-11-22 11:47   ` Johannes Schindelin
2021-11-14 21:43 ` [PATCH 0/1] Add a test balloon for C99 brian m. carlson
2021-11-15  7:00 ` Junio C Hamano
2021-11-15 22:41   ` brian m. carlson
2021-11-16 19:02     ` Junio C Hamano
2021-11-17  1:51       ` brian m. carlson
2021-11-16  2:12 ` [PATCH v2 0/1] Add a test balloon for C99 support brian m. carlson
2021-11-16  2:12   ` [PATCH v2 1/1] git-compat-util: add " brian m. carlson
2021-11-16 12:19     ` Jeff King
2021-11-16 12:54       ` Ævar Arnfjörð Bjarmason [this message]
2021-11-16 14:54         ` Jeff King
2021-11-17  2:53           ` brian m. carlson
2021-11-17  3:01             ` Jeff King
2021-11-17 23:18               ` brian m. carlson
2021-11-17 23:45                 ` Carlo Arenas
2021-11-18  2:26                   ` Ævar Arnfjörð Bjarmason
2021-11-18 19:10                 ` Junio C Hamano
2021-11-17  8:49           ` Junio C Hamano
2021-11-16 19:44       ` Phillip Wood
2021-11-17  1:44       ` brian m. carlson
2021-11-17  2:58         ` Jeff King
2021-11-30 20:43 ` Microsoft's C language policy (was: [PATCH 0/1] Add a test balloon for C99) Ævar Arnfjörð Bjarmason
2021-11-30 22:37   ` brian m. carlson
2021-12-01  1:40 ` [PATCH v3 0/1] Add a test balloon for C99 support brian m. carlson
2021-12-01  1:40   ` [PATCH v3 1/1] git-compat-util: add " brian m. carlson
2021-12-02 17:38     ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=211116.86pmr0p82k.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).