Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT
- From
Ben Peart <peartben@gmail.com>
- Date
- Jul 10, 2017, 14:57 UTC
- 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:
Show 45 quoted lines
> On Sun, Jul 09, 2017 at 10:05:49AM -0700, Junio C Hamano wrote: > >> René Scharfe <l.s.r@web.de> 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.
Show 14 quoted lines
> 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 <peff@peff.net> > --- > 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.
Show 17 quoted lines
> 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
>