git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ben Peart" <peartben@gmail.com>, "Jeff King" <peff@peff.net>,
	"René Scharfe" <l.s.r@web.de>,
	"Andreas Schwab" <schwab@linux-m68k.org>,
	"Git List" <git@vger.kernel.org>, "Johannes Sixt" <j6t@kdbg.org>
Subject: Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT
Date: Wed, 12 Jul 2017 21:12:55 +0200	[thread overview]
Message-ID: <87d195zcy0.fsf@gmail.com> (raw)
In-Reply-To: <xmqqeftn3s7t.fsf@gitster.mtv.corp.google.com>


On Tue, Jul 11 2017, Junio C. Hamano jotted:

> Ben Peart <peartben@gmail.com> writes:
>
>>> If this patch can survive a few releases without complaint,
>>> then we can feel more confident that designated initializers
>>> are widely supported by our user base.  It also is an
>>> indication that other C99 features may be supported, but not
>>> a guarantee (e.g., gcc had designated initializers before
>>> C99 existed).
>>
>> Correct.  MSVC also supports designated initializers but does not
>> fully support C99.
>
> Thanks for a datapoint.
>
> Just so that people do not misunderstand, it is not our goal to
> declare that now you need a fully C99 compiler to build Git.
>
> When deciding what shell scripting tools with what options in our
> scripted Porcelains and tests, we use POSIX.1 as a rough guideline.
> We say "let's not use this, as it is not even in POSIX" but we never
> say "use of it is OK because it is in POSIX", and we sometimes even
> say "even it is in POSIX, various implementation of it is buggy and
> it does not work properly in practice" to certain things [*1*].
>
> C89 has been the base of such a guideline for our C programs, and
> people must not to view this patch as an attempt to raise the base
> to C99.  It is rather an attempt to see how far we can safely raise
> the base by checking some selected useful new features [*2*] that we
> have had occasions to wish that they were available, and designated
> initializer for structure fields is one of them.
>
> We may find out that, after starting with "C89, plus this and that
> feature that are known to be commonly supported", the guideline may
> become more succinct to say "C99, minus this and that feature that
> are not usable on some platforms", if it turns out that majority of
> the systems that are not fully C99 have all of the things we care
> about.  We do not know yet, and we are only at the beginning of the
> journey to find it out.

I think in the context of this desire Johannes Sixt's "Actually, I'm
serious [about let's compile with c++]"[1] should be given some more
consideration.

I've just compiled Git with it and it passes all tests. I think the
endeavor is worthwhile in itself as C++ source-level compatibility for
git.git is clearly easy to achieve, and would effectively give us access
to more compilers (albeit in different modes, but they may discover
novel bugs that also apply to the C mode code).

Most of his patch is just avoiding C++ keywords, e.g. new -> wen, try ->
try_, this -> this_, namespace -> name_space, template -> templ
etc. It's going to be relatively easy to avoid a few keywords as
variable names, especially if we set up CI for it via Travis.

But why do it? Aside from the "more compilers" argument, we may find
that it's going to be much easier to use some C99 features we want by
having C++ source-level compatibility, and on compilers like that may
not support those features in C use the C++ mode that may support those.

I don't know enough about e.g. MSVC to say if that's the case, but if so
that might be an easier way to use some C99 features.

If not C++ support would be interesting for other reasons. Johannes
Sixt: It would be very nice to get those patches on-list.

1. 962da692-8874-191c-59d4-65b9562cf87f@kdbg.org
   (https://public-inbox.org/git/962da692-8874-191c-59d4-65b9562cf87f@kdbg.org/)

> [Footnote]
>
> *1* Like `backtick` command substitutions that is very hard to make
>     them nest properly and impossible to mix portably with quoting.
>
> *2* New, relative to our current practice, that is.

  reply	other threads:[~2017-07-12 19:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10  7:03 [PATCH] strbuf: use designated initializers in STRBUF_INIT Jeff King
2017-07-10 14:57 ` Ben Peart
2017-07-10 16:04   ` Jeff King
2017-07-10 17:57     ` Ben Peart
2017-07-11  5:01   ` Mike Hommey
2017-07-11 15:31   ` Junio C Hamano
2017-07-12 19:12     ` Ævar Arnfjörð Bjarmason [this message]
2017-07-12 21:08       ` Junio C Hamano
2017-07-13 22:24       ` Johannes Sixt
2017-07-10 16:44 ` Junio C Hamano
2017-07-10 17:33   ` Stefan Beller
2017-07-10 21:46     ` Junio C Hamano
2017-07-10 17:10 ` Andreas Schwab
2017-07-10 19:57 ` Johannes Sixt
2017-07-10 20:38   ` Junio C Hamano
2017-07-10 21:11     ` Johannes Sixt
2017-07-10 21:38       ` Junio C Hamano
2017-07-14 16:11         ` Junio C Hamano
2017-07-14 17:13           ` Stefan Beller
2017-07-14 17:36           ` Jeff King
2017-07-14 18:48             ` Junio C Hamano
2017-07-14 19:16               ` Junio C Hamano
2017-07-19 18:19                 ` [PATCH] objects: scope count variable to loop Stefan Beller
2017-07-19 18:23                   ` Brandon Williams
2017-07-24 17:08                     ` Jeff King
2017-07-24 17:12                       ` Stefan Beller
2017-07-24 18:05                         ` Jeff King
2017-07-14 19:28           ` [PATCH] strbuf: use designated initializers in STRBUF_INIT Ævar Arnfjörð Bjarmason
2017-07-14 22:26             ` Junio C Hamano
2017-07-14 22:43           ` Mike Hommey
2017-07-15 11:08             ` Jeff King
2017-07-11  4:38       ` Jeff King
2017-07-11  0:05   ` brian m. carlson
2017-07-11  0:07     ` Stefan Beller
2017-07-11  0:10       ` brian m. carlson
2017-07-11  5:24     ` Johannes Sixt
2017-07-12  1:26       ` brian m. carlson
2017-07-12 18:25         ` Johannes Sixt
2017-07-10 22:41 ` Brandon Williams

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=87d195zcy0.fsf@gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=l.s.r@web.de \
    --cc=peartben@gmail.com \
    --cc=peff@peff.net \
    --cc=schwab@linux-m68k.org \
    /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).