On Tue, Jul 11 2017, Junio C. Hamano jotted: > Ben Peart <peartben@xxxxxxxxx> 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@xxxxxxxx (https://public-inbox.org/git/962da692-8874-191c-59d4-65b9562cf87f@xxxxxxxx/) > [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.
