git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/1] Add a test balloon for C99
Date: Mon, 15 Nov 2021 22:41:03 +0000	[thread overview]
Message-ID: <YZLh/1xkxRGDn76u@camp.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqy25pj43a.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]

On 2021-11-15 at 07:00:25, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > Even for users who would like to target an older version of Windows,
> > such as the no longer supported Windows 7, GCC and Clang are available.
> > The LLVM suite, including Clang, is available pre-compiled for download
> > free of charge.  Using a different compiler is specifically proposed by
> > Microsoft staff[1] as a solution for users who wish to build modern
> > programs for MSVC versions which do not support modern C.
> >
> > As such, we can assume that Git can be safely compiled with C99 or C11
> > support on all operating systems which receive security support, and
> > even some which do not.  Our CI confirms that this series passes all
> > tests.  Let's introduce a test balloon which checks for this support and
> > fails with an error message if it is absent.
> 
> I do not have much against adopting nicer C99 language features in
> principle, but I hope that we are not becoming too Linux centric
> with "other than Linux, as long as Windows is OK in some form,
> everything is peachy" mentality.

It's definitely not my goal to exclude Windows here.  I'm pretty sure
every major Unix platform will handle this fine, and an up to date
MSVC will also handle this fine.

Because compiling Git for Windows is a lot of work (not due to any
failing of that project or its members, just the fact that it requires a
lot of components to be assembled, including a full POSIX environment),
it's not very likely we're going to see a lot of people doing it, since
almost all Windows users are going to be using the regular releases.
It's also likely that they're going to be using some automated CI system
which will likely support a recent version of the compiler.

However, we have in the past heard screaming from people who want to
support old versions of Windows, so my point here is that there are
options if they can't use MSVC for any reason and those options are
easy, accessible, and free of charge.  I should point out that we
already require people on non-Linux Unix systems to install GNU make and
possibly also a shell (if theirs doesn't support the local keyword), so
installing suitable tooling to build Git isn't without precedent.

> If there is a rogue implementation that claims to do C99 with
> STDC_VERSION without properly supporting some language constructs we
> care about, that would be bad.  That is why I tend to prefer the
> approach we have taken so far, validating selected features we care
> about one by one with pointed weather balloon tests, over "the
> compiler says it supports that version, so we trust them".

I think this is going to be unlikely.  People can and do expect to rely
on __STDC_VERSION__ working properly, and it's likely any compiler which
lacked those features has long been fixed.

> Perhaps we can do this, and a more pointed "break compilers without
> variable decl in for() loop" change, at the same time.  After the
> latter turns out to be noise free, we can update CodingGuidelines.

As I mentioned in another thread, we'll need a patch like this first to
enable proper handling for older compilers, but I think that should be
fine on top.

> Even when we clear C99 as the whole, I'd be hesitant to allow
> certain things from the language (not because compilers do not grok
> them, but purely from style and readability point of view).  For
> example, -Wdecl-after-statement is a good discipline to follow even
> if your compiler allows them.

I think specifically -Wdecl-after-statement depends on the situation.
There are many cases where it's less error prone or easier to read if
the variable is declared immediately before it's used.

Regardless, I don't think we need to decide this now.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2021-11-15 23:44 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 [this message]
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
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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=YZLh/1xkxRGDn76u@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).