From: Ben Peart Date: Mon, 10 Jul 2017 14:57:57 GMT Subject: Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT Message-ID: <4d4f2af7-60b9-5866-50bc-ecf002f74cba@gmail.com> In-Reply-To: <20170710070342.txmlwwq6gvjkwtw7@sigill.intra.peff.net> On 7/10/2017 3:03 AM, Jeff King wrote: > On Sun, Jul 09, 2017 at 10:05:49AM -0700, Junio C Hamano wrote: > >> René Scharfe writes: >> >>> I wonder when we can begin to target C99 in git's source, though. :) >> >> Let's get the ball rolling by starting to use some of the useful >> features like designated initializers, perhaps, in a small, critical >> and reasonably stable part of the system that anybody must compile, >> leave it in one full release cycle or two, and when we hear nobody >> complains, introduce it en masse for the remainder of the system? >> >> That way, we will see if there are people who need pre-C99 soon >> enough, and we won't have to scramble reverting too many changes >> when it happens. > > Neat idea. Something like this? > > -- >8 -- > Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT > > There are certain C99 features that might be nice to use in > our code base, but we've hesitated to do so in order to > avoid breaking compatibility with older compilers. But we > don't actually know if people are even using pre-C99 > compilers these days. > > One way to figure that out is to introduce a very small use > of a feature, and see if anybody complains. The strbuf code > is a good place to do this for a few reasons: > > - it always gets compiled, no matter which Makefile knobs > have been tweaked. > > - it's very stable; this definition hasn't changed in a > long time and is not likely to (so if we have to revert, > it's unlikely to cause headaches) > > 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. > And if we do get complaints, then we'll have gained some > data and we can easily revert this patch. > > Signed-off-by: Jeff King > --- > I suspected we could also do something with __STDC_VERSION__, though I > wonder what compilers set it to when not in standards-compliant mode. > gcc-6 claims C11 when no specific -std flag is given. > > And obviously before releasing this or anything similar, it would be > nice to see results from people building pu. I'm especially curious > whether MSVC would work with this (or if people even still use it, since > Git for Windows is pretty mature?). > We do use MSVC internally as that gives us access to the great debuggers and profilers on the Windows platform. Fortunately, this particular C99 construct _is_ supported by MSVC. I applied the patch below and complied it with both MSVC and gcc for Windows and both builds succeeded. > strbuf.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/strbuf.h b/strbuf.h > index 2075384e0..e705b94db 100644 > --- a/strbuf.h > +++ b/strbuf.h > @@ -68,7 +68,7 @@ struct strbuf { > }; > > extern char strbuf_slopbuf[]; > -#define STRBUF_INIT { 0, 0, strbuf_slopbuf } > +#define STRBUF_INIT { .alloc = 0, .len = 0, .buf = strbuf_slopbuf } > > /** > * Life Cycle Functions >