* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support [not found] ` <20211114211622.1465981-2-sandals@crustytoothpaste.net> @ 2021-11-16 10:30 ` Johannes Schindelin 2021-11-17 8:29 ` Junio C Hamano 0 siblings, 1 reply; 20+ messages in thread From: Johannes Schindelin @ 2021-11-16 10:30 UTC (permalink / raw) To: brian m. carlson Cc: git, Carlo Marcelo Arenas Belón, Ævar Arnfjörð Bjarmason, Jeff King, Junio C Hamano Hi brian, On Sun, 14 Nov 2021, brian m. carlson wrote: > The C99 standard was released in January 1999, now 22 years ago. It > provides a variety of useful features, including variadic arguments for > macros, declarations after statements, variable length arrays, and a > wide variety of other useful features, many of which we already use. > > We'd like to take advantage of these features, but we want to be > cautious. As far as we know, all major compilers now support C99 or a > later C standard, such as C11 or C17. POSIX has required C99 support as > a requirement for the 2001 revision, so we can safely assume any POSIX > system which we are interested in supporting has C99. > > Even MSVC, long a holdout against modern C, now supports both C11 and > C17 with an appropriate update. Moreover, even if people are using an > older version of MSVC on these systems, they will generally need some > implementation of the standard Unix utilities for the testsuite, and GNU > coreutils, the most common option, has required C99 since 2009. > Therefore, we can safely assume that a suitable version of GCC or clang > is available to users even if their version of MSVC is not sufficiently > capable. > > Let's add a test balloon to git-compat-util.h to see if anyone is using > an older compiler. We'll add a comment telling people how to enable > this functionality on GCC and Clang, even though modern versions of both > will automatically do the right thing, and ask people still experiencing > a problem to report that to us on the list. > > Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we > use a well-known hack of using "- 0". On compilers with this macro, it > doesn't change the value, and on C89 compilers, the macro will be > replaced with nothing, and our value will be 0. > > Sparse is also updated with a reference to the gnu99 standard, without > which it defaults to C89. > > Update the cmake configuration to require C11 for MSVC. We do this > because this will make MSVC to use C11, since it does not explicitly > support C99. We do this with a compiler options because setting the > C_STANDARD option does not work in our CI on MSVC and at the moment, we > don't want to require C11 for Unix compilers. I am all in favor of this patch! Thank you, Dscho > > Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> > --- > Makefile | 4 ++-- > contrib/buildsystems/CMakeLists.txt | 3 +-- > git-compat-util.h | 12 ++++++++++++ > 3 files changed, 15 insertions(+), 4 deletions(-) > > diff --git a/Makefile b/Makefile > index 12be39ac49..22d9e67542 100644 > --- a/Makefile > +++ b/Makefile > @@ -1204,7 +1204,7 @@ endif > # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be > # tweaked by config.* below as well as the command-line, both of > # which'll override these defaults. > -CFLAGS = -g -O2 -Wall > +CFLAGS = -g -O2 -Wall -std=gnu99 > LDFLAGS = > CC_LD_DYNPATH = -Wl,-rpath, > BASIC_CFLAGS = -I. > @@ -1215,7 +1215,7 @@ ARFLAGS = rcs > PTHREAD_CFLAGS = > > # For the 'sparse' target > -SPARSE_FLAGS ?= > +SPARSE_FLAGS ?= -std=gnu99 > SP_EXTRA_FLAGS = -Wno-universal-initializer > > # For informing GIT-BUILD-OPTIONS of the SANITIZE=leak target > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt > index fd1399c440..91e8525fa9 100644 > --- a/contrib/buildsystems/CMakeLists.txt > +++ b/contrib/buildsystems/CMakeLists.txt > @@ -208,7 +208,7 @@ endif() > if(CMAKE_C_COMPILER_ID STREQUAL "MSVC") > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}) > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}) > - add_compile_options(/MP) > + add_compile_options(/MP /std:c11) > endif() > > #default behaviour > @@ -600,7 +600,6 @@ endif() > list(REMOVE_DUPLICATES excluded_progs) > list(REMOVE_DUPLICATES PROGRAMS_BUILT) > > - > foreach(p ${excluded_progs}) > list(APPEND EXCLUSION_PROGS --exclude-program ${p} ) > endforeach() > diff --git a/git-compat-util.h b/git-compat-util.h > index d70ce14286..6d995bdc0f 100644 > --- a/git-compat-util.h > +++ b/git-compat-util.h > @@ -1,6 +1,18 @@ > #ifndef GIT_COMPAT_UTIL_H > #define GIT_COMPAT_UTIL_H > > +#if __STDC_VERSION__ - 0 < 199901L > +/* > + * Git is in a testing period for mandatory C99 support in the compiler. If > + * your compiler is reasonably recent, you can try to enable C99 support (or, > + * for MSVC, C11 support). If you encounter a problem and can't enable C99 > + * support with your compiler and don't have access to one with this support, > + * such as GCC or Clang, you can remove this #if directive, but please report > + * the details of your system to git@vger.kernel.org. > + */ > +#error "Required C99 support is in a test phase. Please see git-compat-util.h for more details." > +#endif > + > #ifdef USE_MSVC_CRTDBG > /* > * For these to work they must appear very early in each > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-16 10:30 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 support Johannes Schindelin @ 2021-11-17 8:29 ` Junio C Hamano 2021-11-22 11:44 ` Johannes Schindelin 0 siblings, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2021-11-17 8:29 UTC (permalink / raw) To: Johannes Schindelin Cc: brian m. carlson, git, Carlo Marcelo Arenas Belón, Ævar Arnfjörð Bjarmason, Jeff King Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> Even MSVC, long a holdout against modern C, now supports both C11 and >> C17 with an appropriate update. Moreover, even if people are using an >> older version of MSVC on these systems, they will generally need some >> implementation of the standard Unix utilities for the testsuite, and GNU >> coreutils, the most common option, has required C99 since 2009. >> Therefore, we can safely assume that a suitable version of GCC or clang >> is available to users even if their version of MSVC is not sufficiently >> capable. > > I am all in favor of this patch! I like the direction, but ... >> diff --git a/Makefile b/Makefile >> index 12be39ac49..22d9e67542 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -1204,7 +1204,7 @@ endif >> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be >> # tweaked by config.* below as well as the command-line, both of >> # which'll override these defaults. >> -CFLAGS = -g -O2 -Wall >> +CFLAGS = -g -O2 -Wall -std=gnu99 ... as has been already pointed out, this part probably should not be there. It is not our intention to require gcc/clang, or to constrain newer systems to gnu99. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-17 8:29 ` Junio C Hamano @ 2021-11-22 11:44 ` Johannes Schindelin 2021-11-22 13:05 ` Ævar Arnfjörð Bjarmason 2021-11-22 17:27 ` Junio C Hamano 0 siblings, 2 replies; 20+ messages in thread From: Johannes Schindelin @ 2021-11-22 11:44 UTC (permalink / raw) To: Junio C Hamano Cc: brian m. carlson, git, Carlo Marcelo Arenas Belón, Ævar Arnfjörð Bjarmason, Jeff King Hi Junio & brian, On Wed, 17 Nov 2021, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> Even MSVC, long a holdout against modern C, now supports both C11 and > >> C17 with an appropriate update. Moreover, even if people are using an > >> older version of MSVC on these systems, they will generally need some > >> implementation of the standard Unix utilities for the testsuite, and GNU > >> coreutils, the most common option, has required C99 since 2009. > >> Therefore, we can safely assume that a suitable version of GCC or clang > >> is available to users even if their version of MSVC is not sufficiently > >> capable. > > > > I am all in favor of this patch! > > I like the direction, but ... > > >> diff --git a/Makefile b/Makefile > >> index 12be39ac49..22d9e67542 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -1204,7 +1204,7 @@ endif > >> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be > >> # tweaked by config.* below as well as the command-line, both of > >> # which'll override these defaults. > >> -CFLAGS = -g -O2 -Wall > >> +CFLAGS = -g -O2 -Wall -std=gnu99 > > ... as has been already pointed out, this part probably should not > be there. It is not our intention to require gcc/clang, or to > constrain newer systems to gnu99. Another data point in favor of dropping this: our FreeBSD CI build reports a compile error with this: [...] archive.c:337:35: error: '_Generic' is a C11 extension [-Werror,-Wc11-extensions] strbuf_addstr(&path_in_archive, basename(path)); ^ /usr/include/libgen.h:61:21: note: expanded from macro 'basename' #define basename(x) __generic(x, const char *, __old_basename, basename)(x) ^ /usr/include/sys/cdefs.h:329:2: note: expanded from macro '__generic' _Generic(expr, t: yes, default: no) ^ 1 error generated. I verified in https://github.com/gitgitgadget/git/pull/1082 that this patch is indeed the cause of this compile error. Ciao, Dscho ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-22 11:44 ` Johannes Schindelin @ 2021-11-22 13:05 ` Ævar Arnfjörð Bjarmason 2021-11-22 17:27 ` Junio C Hamano 1 sibling, 0 replies; 20+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2021-11-22 13:05 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, brian m. carlson, git, Carlo Marcelo Arenas Belón, Jeff King On Mon, Nov 22 2021, Johannes Schindelin wrote: > Hi Junio & brian, > > On Wed, 17 Nov 2021, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> >> >> Even MSVC, long a holdout against modern C, now supports both C11 and >> >> C17 with an appropriate update. Moreover, even if people are using an >> >> older version of MSVC on these systems, they will generally need some >> >> implementation of the standard Unix utilities for the testsuite, and GNU >> >> coreutils, the most common option, has required C99 since 2009. >> >> Therefore, we can safely assume that a suitable version of GCC or clang >> >> is available to users even if their version of MSVC is not sufficiently >> >> capable. >> > >> > I am all in favor of this patch! >> >> I like the direction, but ... >> >> >> diff --git a/Makefile b/Makefile >> >> index 12be39ac49..22d9e67542 100644 >> >> --- a/Makefile >> >> +++ b/Makefile >> >> @@ -1204,7 +1204,7 @@ endif >> >> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be >> >> # tweaked by config.* below as well as the command-line, both of >> >> # which'll override these defaults. >> >> -CFLAGS = -g -O2 -Wall >> >> +CFLAGS = -g -O2 -Wall -std=gnu99 >> >> ... as has been already pointed out, this part probably should not >> be there. It is not our intention to require gcc/clang, or to >> constrain newer systems to gnu99. > > Another data point in favor of dropping this: our FreeBSD CI build reports > a compile error with this: > > [...] > archive.c:337:35: error: '_Generic' is a C11 extension > [-Werror,-Wc11-extensions] > strbuf_addstr(&path_in_archive, basename(path)); > ^ > /usr/include/libgen.h:61:21: note: expanded from macro 'basename' > #define basename(x) __generic(x, const char *, __old_basename, basename)(x) > ^ > /usr/include/sys/cdefs.h:329:2: note: expanded from macro '__generic' > _Generic(expr, t: yes, default: no) > ^ > 1 error generated. > > I verified in https://github.com/gitgitgadget/git/pull/1082 that this > patch is indeed the cause of this compile error. As noted in another reply I don't think this -std=* thing is worth it, but this isn't so much a case of breakage with this patch in particular, but revealing an existing issue of us implicitly requiring C11 on FreeBSD. Whether that's worth pursuing is another matter, but it's not some inherent issue in this approach, but just a platform-specific nit we could fix. Either by saying -std=c11 on that platform, or presumably defining NO_LIBGEN_H if we wanted to proceed in lockstep with C99-but-not-C11 everyhere. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-22 11:44 ` Johannes Schindelin 2021-11-22 13:05 ` Ævar Arnfjörð Bjarmason @ 2021-11-22 17:27 ` Junio C Hamano 2021-11-22 17:52 ` Carlo Arenas 1 sibling, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2021-11-22 17:27 UTC (permalink / raw) To: Johannes Schindelin Cc: brian m. carlson, git, Carlo Marcelo Arenas Belón, Ævar Arnfjörð Bjarmason, Jeff King Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> I like the direction, but ... >> >> >> diff --git a/Makefile b/Makefile >> >> index 12be39ac49..22d9e67542 100644 >> >> --- a/Makefile >> >> +++ b/Makefile >> >> @@ -1204,7 +1204,7 @@ endif >> >> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be >> >> # tweaked by config.* below as well as the command-line, both of >> >> # which'll override these defaults. >> >> -CFLAGS = -g -O2 -Wall >> >> +CFLAGS = -g -O2 -Wall -std=gnu99 >> >> ... as has been already pointed out, this part probably should not >> be there. It is not our intention to require gcc/clang, or to >> constrain newer systems to gnu99. > > Another data point in favor of dropping this: our FreeBSD CI build reports > a compile error with this: > > [...] > archive.c:337:35: error: '_Generic' is a C11 extension > [-Werror,-Wc11-extensions] > strbuf_addstr(&path_in_archive, basename(path)); > ^ > /usr/include/libgen.h:61:21: note: expanded from macro 'basename' > #define basename(x) __generic(x, const char *, __old_basename, basename)(x) > ^ > /usr/include/sys/cdefs.h:329:2: note: expanded from macro '__generic' > _Generic(expr, t: yes, default: no) > ^ > 1 error generated. > > I verified in https://github.com/gitgitgadget/git/pull/1082 that this > patch is indeed the cause of this compile error. Thanks. I took a look at #1082, which reverted this one (and nothing else) to see a test succeds, and then re-reverted it to see it fail (but apparently only on FreeBSD/Cirrus). I had an impression that it was claimed that without this, the other weatherbaloon for "for (type var=..." would not fly in some of the jobs we have at CI? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-22 17:27 ` Junio C Hamano @ 2021-11-22 17:52 ` Carlo Arenas 2021-11-22 18:58 ` Junio C Hamano 0 siblings, 1 reply; 20+ messages in thread From: Carlo Arenas @ 2021-11-22 17:52 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King On Mon, Nov 22, 2021 at 9:27 AM Junio C Hamano <gitster@pobox.com> wrote: > I had an impression that it was claimed that without this, the other > weatherbaloon for "for (type var=..." would not fly in some of the > jobs we have at CI? It wouldn't if we have a CI job that tests with gcc < 5 but the last version of that job died with travis-ci.org Carlo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-22 17:52 ` Carlo Arenas @ 2021-11-22 18:58 ` Junio C Hamano 2021-11-22 20:52 ` Junio C Hamano 0 siblings, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2021-11-22 18:58 UTC (permalink / raw) To: Carlo Arenas Cc: Johannes Schindelin, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King Carlo Arenas <carenas@gmail.com> writes: > On Mon, Nov 22, 2021 at 9:27 AM Junio C Hamano <gitster@pobox.com> wrote: > >> I had an impression that it was claimed that without this, the other >> weatherbaloon for "for (type var=..." would not fly in some of the >> jobs we have at CI? > > It wouldn't if we have a CI job that tests with gcc < 5 but the last > version of that job died with travis-ci.org I was wondering how Dscho's test was not failing, and that is an easy answer to that question ;-) If we wanted to resurrect that CI job, we can always add it in the CI definition anyway, so I am OK with that, too. Thanks. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-22 18:58 ` Junio C Hamano @ 2021-11-22 20:52 ` Junio C Hamano 2021-11-22 22:03 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty Johannes Schindelin 0 siblings, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2021-11-22 20:52 UTC (permalink / raw) To: Carlo Arenas Cc: Johannes Schindelin, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King Junio C Hamano <gitster@pobox.com> writes: > Carlo Arenas <carenas@gmail.com> writes: > >> On Mon, Nov 22, 2021 at 9:27 AM Junio C Hamano <gitster@pobox.com> wrote: >> >>> I had an impression that it was claimed that without this, the other >>> weatherbaloon for "for (type var=..." would not fly in some of the >>> jobs we have at CI? >> >> It wouldn't if we have a CI job that tests with gcc < 5 but the last >> version of that job died with travis-ci.org > > I was wondering how Dscho's test was not failing, and that is an > easy answer to that question ;-) > > If we wanted to resurrect that CI job, we can always add it in the > CI definition anyway, so I am OK with that, too. But if we were to do so, perhaps we'd want something like what I gave at https://lore.kernel.org/git/xmqqy25lwa86.fsf@gitster.g/ in its place to avoid confusing people. Let me update that topic before dropping the one under discussion. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty 2021-11-22 20:52 ` Junio C Hamano @ 2021-11-22 22:03 ` Johannes Schindelin 2021-11-22 22:10 ` Junio C Hamano 0 siblings, 1 reply; 20+ messages in thread From: Johannes Schindelin @ 2021-11-22 22:03 UTC (permalink / raw) To: Junio C Hamano Cc: Carlo Arenas, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King Hi Junio, On Mon, 22 Nov 2021, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Carlo Arenas <carenas@gmail.com> writes: > > > >> On Mon, Nov 22, 2021 at 9:27 AM Junio C Hamano <gitster@pobox.com> wrote: > >> > >>> I had an impression that it was claimed that without this, the other > >>> weatherbaloon for "for (type var=..." would not fly in some of the > >>> jobs we have at CI? > >> > >> It wouldn't if we have a CI job that tests with gcc < 5 but the last > >> version of that job died with travis-ci.org > > > > I was wondering how Dscho's test was not failing, and that is an > > easy answer to that question ;-) > > > > If we wanted to resurrect that CI job, we can always add it in the > > CI definition anyway, so I am OK with that, too. > > But if we were to do so, perhaps we'd want something like what I > gave at https://lore.kernel.org/git/xmqqy25lwa86.fsf@gitster.g/ in > its place to avoid confusing people. That sounds like a good course of action to me. Please note that the MSVC-related adjustment of the `FLEX_ARRAY` block is still needed, I think. Ciao, Dscho P.S.: In case it was not clear yet, I am in favor of going forward with the C99 weather balloon. We should try to move in that direction, slowly and gently, as is our custom. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty 2021-11-22 22:03 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty Johannes Schindelin @ 2021-11-22 22:10 ` Junio C Hamano 2021-11-22 22:22 ` Carlo Arenas 2021-11-23 12:32 ` Johannes Schindelin 0 siblings, 2 replies; 20+ messages in thread From: Junio C Hamano @ 2021-11-22 22:10 UTC (permalink / raw) To: Johannes Schindelin Cc: Carlo Arenas, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> But if we were to do so, perhaps we'd want something like what I >> gave at https://lore.kernel.org/git/xmqqy25lwa86.fsf@gitster.g/ in >> its place to avoid confusing people. > > That sounds like a good course of action to me. > > Please note that the MSVC-related adjustment of the `FLEX_ARRAY` block is > still needed, I think. The "something like what I gave ... to avoid confusing people" patch is following up on the direction to drop the patch with -std=gnu99 change. IIRC, your MSVC adjustment was to tweak that patch we were discussing of dropping, so even if it is still needed, it won't be part of what I was doing. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty 2021-11-22 22:10 ` Junio C Hamano @ 2021-11-22 22:22 ` Carlo Arenas 2021-11-23 12:32 ` Johannes Schindelin 1 sibling, 0 replies; 20+ messages in thread From: Carlo Arenas @ 2021-11-22 22:22 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King On Mon, Nov 22, 2021 at 2:10 PM Junio C Hamano <gitster@pobox.com> wrote: > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> But if we were to do so, perhaps we'd want something like what I > >> gave at https://lore.kernel.org/git/xmqqy25lwa86.fsf@gitster.g/ in > >> its place to avoid confusing people. > > > > That sounds like a good course of action to me. > > > > Please note that the MSVC-related adjustment of the `FLEX_ARRAY` block is > > still needed, I think. > > The "something like what I gave ... to avoid confusing people" patch > is following up on the direction to drop the patch with -std=gnu99 > change. IIRC, your MSVC adjustment was to tweak that patch we were > discussing of dropping, so even if it is still needed, it won't be > part of what I was doing. I think it will still be needed, I have somewhere indeed a bugfix (which I never got back to clean up enough for sending) to that section because it was not C89 safe either, which is what dscho is likely fixing from the point of view of MSVC that doesn't support the GNU syntax that we use as a fallback eagerly than we should. FWIW I got the chance to try to build in a long unmaintained debian 6 (AKA squeeze) with gcc 4.4.5 and was greeted by the following edited message: error: 'for' loop initial declarations are only allowed in C99 mode note: use option -std=c99 or -std=gnu99 to compile your code So I think whatever we do, likely it wouldn't be confusing to whoever is affected. Carlo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty 2021-11-22 22:10 ` Junio C Hamano 2021-11-22 22:22 ` Carlo Arenas @ 2021-11-23 12:32 ` Johannes Schindelin 2021-11-23 20:17 ` Junio C Hamano 1 sibling, 1 reply; 20+ messages in thread From: Johannes Schindelin @ 2021-11-23 12:32 UTC (permalink / raw) To: Junio C Hamano Cc: Carlo Arenas, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King Hi Junio, On Mon, 22 Nov 2021, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> But if we were to do so, perhaps we'd want something like what I > >> gave at https://lore.kernel.org/git/xmqqy25lwa86.fsf@gitster.g/ in > >> its place to avoid confusing people. > > > > That sounds like a good course of action to me. > > > > Please note that the MSVC-related adjustment of the `FLEX_ARRAY` block is > > still needed, I think. > > The "something like what I gave ... to avoid confusing people" patch > is following up on the direction to drop the patch with -std=gnu99 > change. IIRC, your MSVC adjustment was to tweak that patch we were > discussing of dropping, so even if it is still needed, it won't be > part of what I was doing. I thought we were only dropping the `--std=gnu99` part, not the change to the `git-compat-util.h` header file, nor the patch to the CMake configuration for MS Visual C. Ciao, Dscho ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty 2021-11-23 12:32 ` Johannes Schindelin @ 2021-11-23 20:17 ` Junio C Hamano 2021-11-24 15:10 ` brian m. carlson 0 siblings, 1 reply; 20+ messages in thread From: Junio C Hamano @ 2021-11-23 20:17 UTC (permalink / raw) To: Johannes Schindelin Cc: Carlo Arenas, brian m. carlson, git, Ævar Arnfjörð Bjarmason, Jeff King Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > Hi Junio, > > On Mon, 22 Nov 2021, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> >> >> But if we were to do so, perhaps we'd want something like what I >> >> gave at https://lore.kernel.org/git/xmqqy25lwa86.fsf@gitster.g/ in >> >> its place to avoid confusing people. >> > >> > That sounds like a good course of action to me. >> > >> > Please note that the MSVC-related adjustment of the `FLEX_ARRAY` block is >> > still needed, I think. >> >> The "something like what I gave ... to avoid confusing people" patch >> is following up on the direction to drop the patch with -std=gnu99 >> change. IIRC, your MSVC adjustment was to tweak that patch we were >> discussing of dropping, so even if it is still needed, it won't be >> part of what I was doing. > > I thought we were only dropping the `--std=gnu99` part, not the change to > the `git-compat-util.h` header file, nor the patch to the CMake > configuration for MS Visual C. Ah, yes, I think these parts need to be kept. I am just dropping the latest iteration with -std=gnu99 from consideration to merge down to 'next' and below. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty 2021-11-23 20:17 ` Junio C Hamano @ 2021-11-24 15:10 ` brian m. carlson 0 siblings, 0 replies; 20+ messages in thread From: brian m. carlson @ 2021-11-24 15:10 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Carlo Arenas, git, Ævar Arnfjörð Bjarmason, Jeff King [-- Attachment #1: Type: text/plain, Size: 722 bytes --] On 2021-11-23 at 20:17:42, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > I thought we were only dropping the `--std=gnu99` part, not the change to > > the `git-compat-util.h` header file, nor the patch to the CMake > > configuration for MS Visual C. > > Ah, yes, I think these parts need to be kept. I am just dropping > the latest iteration with -std=gnu99 from consideration to merge > down to 'next' and below. I'll try to get a v3 out relatively soon with those changes. Due to visiting family in the U.S., I've been a bit busy with things, but I should have some time coming up to do a v3. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 262 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 0/1] Add a test balloon for C99 @ 2021-11-14 21:24 brian m. carlson 2021-11-14 21:24 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 support brian m. carlson 0 siblings, 1 reply; 20+ messages in thread From: brian m. carlson @ 2021-11-14 21:24 UTC (permalink / raw) To: git The C99 standard, more formally known as ISO/IEC 9899:1999, was, as its name suggests, was ratified in 1999, more than 20 years ago[0]. It has a variety of nice features, including loop variable initialization, that are available to most modern programmers. In fact, POSIX 1003.1-2001 and the Single Unix Specification version 3, made its use mandatory through the c99 command. As a practical matter, all known Unix systems which receive security support have support for these standards or their successors, POSIX 1003.1-2018 and the Single Unix Specification version 4, and as such, we can safely assume support for C99 there. Unfortunately, Microsoft for many years refused[1] to support C99 in MSVC, and still does not officially do so. However, they recently added support for C11 and C17, which are sufficient for modern programming. These require a newer version of MSVC, including an updated SDK. The SDK update is available for download free of charge, and most public CI systems have support for both the updated MSVC and the SDK update. 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. [0] The reader will note that there are people working professionally in this industry who were not yet born at the time C99 was ratified. Thus, this occurred quite a long time ago indeed. [1] https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ brian m. carlson (1): git-compat-util: add a test balloon for C99 support Makefile | 4 ++-- contrib/buildsystems/CMakeLists.txt | 3 +-- git-compat-util.h | 12 ++++++++++++ 3 files changed, 15 insertions(+), 4 deletions(-) ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-14 21:24 [PATCH 0/1] Add a test balloon for C99 brian m. carlson @ 2021-11-14 21:24 ` brian m. carlson 2021-11-15 1:14 ` Ævar Arnfjörð Bjarmason ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: brian m. carlson @ 2021-11-14 21:24 UTC (permalink / raw) To: git The C99 standard was released in January 1999, now 22 years ago. It provides a variety of useful features, including variadic arguments for macros, declarations after statements, variable length arrays, and a wide variety of other useful features, many of which we already use. We'd like to take advantage of these features, but we want to be cautious. As far as we know, all major compilers now support C99 or a later C standard, such as C11 or C17. POSIX has required C99 support as a requirement for the 2001 revision, so we can safely assume any POSIX system which we are interested in supporting has C99. Even MSVC, long a holdout against modern C, now supports both C11 and C17 with an appropriate update. Moreover, even if people are using an older version of MSVC on these systems, they will generally need some implementation of the standard Unix utilities for the testsuite, and GNU coreutils, the most common option, has required C99 since 2009. Therefore, we can safely assume that a suitable version of GCC or clang is available to users even if their version of MSVC is not sufficiently capable. Let's add a test balloon to git-compat-util.h to see if anyone is using an older compiler. We'll add a comment telling people how to enable this functionality on GCC and Clang, even though modern versions of both will automatically do the right thing, and ask people still experiencing a problem to report that to us on the list. Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we use a well-known hack of using "- 0". On compilers with this macro, it doesn't change the value, and on C89 compilers, the macro will be replaced with nothing, and our value will be 0. Sparse is also updated with a reference to the gnu99 standard, without which it defaults to C89. Update the cmake configuration to require C11 for MSVC. We do this because this will make MSVC to use C11, since it does not explicitly support C99. We do this with a compiler options because setting the C_STANDARD option does not work in our CI on MSVC and at the moment, we don't want to require C11 for Unix compilers. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- Makefile | 4 ++-- contrib/buildsystems/CMakeLists.txt | 3 +-- git-compat-util.h | 12 ++++++++++++ 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 12be39ac49..22d9e67542 100644 --- a/Makefile +++ b/Makefile @@ -1204,7 +1204,7 @@ endif # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be # tweaked by config.* below as well as the command-line, both of # which'll override these defaults. -CFLAGS = -g -O2 -Wall +CFLAGS = -g -O2 -Wall -std=gnu99 LDFLAGS = CC_LD_DYNPATH = -Wl,-rpath, BASIC_CFLAGS = -I. @@ -1215,7 +1215,7 @@ ARFLAGS = rcs PTHREAD_CFLAGS = # For the 'sparse' target -SPARSE_FLAGS ?= +SPARSE_FLAGS ?= -std=gnu99 SP_EXTRA_FLAGS = -Wno-universal-initializer # For informing GIT-BUILD-OPTIONS of the SANITIZE=leak target diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt index fd1399c440..91e8525fa9 100644 --- a/contrib/buildsystems/CMakeLists.txt +++ b/contrib/buildsystems/CMakeLists.txt @@ -208,7 +208,7 @@ endif() if(CMAKE_C_COMPILER_ID STREQUAL "MSVC") set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}) - add_compile_options(/MP) + add_compile_options(/MP /std:c11) endif() #default behaviour @@ -600,7 +600,6 @@ endif() list(REMOVE_DUPLICATES excluded_progs) list(REMOVE_DUPLICATES PROGRAMS_BUILT) - foreach(p ${excluded_progs}) list(APPEND EXCLUSION_PROGS --exclude-program ${p} ) endforeach() diff --git a/git-compat-util.h b/git-compat-util.h index d70ce14286..6d995bdc0f 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -1,6 +1,18 @@ #ifndef GIT_COMPAT_UTIL_H #define GIT_COMPAT_UTIL_H +#if __STDC_VERSION__ - 0 < 199901L +/* + * Git is in a testing period for mandatory C99 support in the compiler. If + * your compiler is reasonably recent, you can try to enable C99 support (or, + * for MSVC, C11 support). If you encounter a problem and can't enable C99 + * support with your compiler and don't have access to one with this support, + * such as GCC or Clang, you can remove this #if directive, but please report + * the details of your system to git@vger.kernel.org. + */ +#error "Required C99 support is in a test phase. Please see git-compat-util.h for more details." +#endif + #ifdef USE_MSVC_CRTDBG /* * For these to work they must appear very early in each ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 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-22 11:47 ` Johannes Schindelin 2 siblings, 1 reply; 20+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2021-11-15 1:14 UTC (permalink / raw) To: brian m. carlson; +Cc: git On Sun, Nov 14 2021, brian m. carlson wrote: > The C99 standard was released in January 1999, now 22 years ago. It > provides a variety of useful features, including variadic arguments for > macros, declarations after statements, variable length arrays, and a > wide variety of other useful features, many of which we already use. > > We'd like to take advantage of these features, but we want to be > cautious. As far as we know, all major compilers now support C99 or a > later C standard, such as C11 or C17. POSIX has required C99 support as > a requirement for the 2001 revision, so we can safely assume any POSIX > system which we are interested in supporting has C99. I like this direction. > Sparse is also updated with a reference to the gnu99 standard, without > which it defaults to C89. Do we really need it in SPARSE_FLAGS though... > @@ -1204,7 +1204,7 @@ endif > # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be > # tweaked by config.* below as well as the command-line, both of > # which'll override these defaults. > -CFLAGS = -g -O2 -Wall > +CFLAGS = -g -O2 -Wall -std=gnu99 > LDFLAGS = > CC_LD_DYNPATH = -Wl,-rpath, > BASIC_CFLAGS = -I. > @@ -1215,7 +1215,7 @@ ARFLAGS = rcs > PTHREAD_CFLAGS = Since $(CFLAGS) ends up in: ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) ... > # For the 'sparse' target > -SPARSE_FLAGS ?= > +SPARSE_FLAGS ?= -std=gnu99 > SP_EXTRA_FLAGS = -Wno-universal-initializer ... and this will be used for this rule: $(SP_OBJ): %.sp: %.c %.o $(QUIET_SP)cgcc -no-compile $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) \ -Wsparse-error \ $(SPARSE_FLAGS) $(SP_EXTRA_FLAGS) $< [...] I.e. unless it needs to be later on the command-line the $(ALL_CFLAGS) should put it there already. Also (and this pre-dates this patch) it's unfortunate that CFLAGS is a mixed bag of compiler tweaking and "mandatory" flags. I think the below would be a better approach, particurly since our own config.mak.uname will override CFLAGS in some cases, and probably everyone who works on git to any degree has a local config.mak which sets it to something already. But why gnu99 and not c99? diff --git a/Makefile b/Makefile index 12be39ac497..7470d627165 100644 --- a/Makefile +++ b/Makefile @@ -1204,10 +1204,14 @@ endif # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be # tweaked by config.* below as well as the command-line, both of # which'll override these defaults. +# +# The MANDATORY_CFLAGS can be similarly overridden, but really +# shouldn't. CFLAGS = -g -O2 -Wall LDFLAGS = CC_LD_DYNPATH = -Wl,-rpath, -BASIC_CFLAGS = -I. +BASIC_CFLAGS = +MANDATORY_CFLAGS = -I. -std=gnu99 BASIC_LDFLAGS = # library flags @@ -1249,7 +1253,7 @@ ALL_COMMANDS_TO_INSTALL += git-upload-archive$(X) ALL_COMMANDS_TO_INSTALL += git-upload-pack$(X) endif -ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) +ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(MANDATORY_CFLAGS) ALL_LDFLAGS = $(LDFLAGS) comma := , ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-15 1:14 ` Ævar Arnfjörð Bjarmason @ 2021-11-15 1:54 ` brian m. carlson 0 siblings, 0 replies; 20+ messages in thread From: brian m. carlson @ 2021-11-15 1:54 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: git [-- Attachment #1: Type: text/plain, Size: 3380 bytes --] On 2021-11-15 at 01:14:42, Ævar Arnfjörð Bjarmason wrote: > > On Sun, Nov 14 2021, brian m. carlson wrote: > > > The C99 standard was released in January 1999, now 22 years ago. It > > provides a variety of useful features, including variadic arguments for > > macros, declarations after statements, variable length arrays, and a > > wide variety of other useful features, many of which we already use. > > > > We'd like to take advantage of these features, but we want to be > > cautious. As far as we know, all major compilers now support C99 or a > > later C standard, such as C11 or C17. POSIX has required C99 support as > > a requirement for the 2001 revision, so we can safely assume any POSIX > > system which we are interested in supporting has C99. > > I like this direction. I felt like a test balloon would go over better than a wholesale changeover. I feel confident we can make this change, and we may even in the not too distant future be able to switch to C11. > > Sparse is also updated with a reference to the gnu99 standard, without > > which it defaults to C89. > > Do we really need it in SPARSE_FLAGS though... > > > @@ -1204,7 +1204,7 @@ endif > > # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be > > # tweaked by config.* below as well as the command-line, both of > > # which'll override these defaults. > > -CFLAGS = -g -O2 -Wall > > +CFLAGS = -g -O2 -Wall -std=gnu99 > > LDFLAGS = > > CC_LD_DYNPATH = -Wl,-rpath, > > BASIC_CFLAGS = -I. > > @@ -1215,7 +1215,7 @@ ARFLAGS = rcs > > PTHREAD_CFLAGS = > > Since $(CFLAGS) ends up in: > > ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) > > ... > > > # For the 'sparse' target > > -SPARSE_FLAGS ?= > > +SPARSE_FLAGS ?= -std=gnu99 > > SP_EXTRA_FLAGS = -Wno-universal-initializer > > ... and this will be used for this rule: > > $(SP_OBJ): %.sp: %.c %.o > $(QUIET_SP)cgcc -no-compile $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) \ > -Wsparse-error \ > $(SPARSE_FLAGS) $(SP_EXTRA_FLAGS) $< [...] > > I.e. unless it needs to be later on the command-line the $(ALL_CFLAGS) > should put it there already. I added it to SPARSE_FLAGS before adding it into CFLAGS, so I can look into dropping it from the former. > Also (and this pre-dates this patch) it's unfortunate that CFLAGS is a > mixed bag of compiler tweaking and "mandatory" flags. I think the below > would be a better approach, particurly since our own config.mak.uname > will override CFLAGS in some cases, and probably everyone who works on > git to any degree has a local config.mak which sets it to something > already. We don't want to do this, because some people are using other compilers (i.e., neither GCC nor clang) that need different options. We definitely do want them to be able to override these values as necessary. I believe config.mak.uname does this in some cases for certain Unix systems. > But why gnu99 and not c99? I'll explain in the commit message in a reroll, but essentially, because we do in some case use GNUisms when we're working with GCC. Right now those are mostly limited to providing C99 features on C89, but I'd like to leave the opportunity open for us to do this in the future. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 262 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 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 3:16 ` Eric Sunshine 2021-11-16 1:53 ` brian m. carlson 2021-11-22 11:47 ` Johannes Schindelin 2 siblings, 1 reply; 20+ messages in thread From: Eric Sunshine @ 2021-11-15 3:16 UTC (permalink / raw) To: brian m. carlson; +Cc: Git List On Sun, Nov 14, 2021 at 4:27 PM brian m. carlson <sandals@crustytoothpaste.net> wrote: > +#if __STDC_VERSION__ - 0 < 199901L > +/* > + * Git is in a testing period for mandatory C99 support in the compiler. If > + * your compiler is reasonably recent, you can try to enable C99 support (or, > + * for MSVC, C11 support). If you encounter a problem and can't enable C99 > + * support with your compiler and don't have access to one with this support, > + * such as GCC or Clang, you can remove this #if directive, but please report > + * the details of your system to git@vger.kernel.org. > + */ > +#error "Required C99 support is in a test phase. Please see git-compat-util.h for more details." You don't need to encapsulate the #error message in double quotes. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 2021-11-15 3:16 ` Eric Sunshine @ 2021-11-16 1:53 ` brian m. carlson 0 siblings, 0 replies; 20+ messages in thread From: brian m. carlson @ 2021-11-16 1:53 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List [-- Attachment #1: Type: text/plain, Size: 1724 bytes --] On 2021-11-15 at 03:16:02, Eric Sunshine wrote: > On Sun, Nov 14, 2021 at 4:27 PM brian m. carlson > <sandals@crustytoothpaste.net> wrote: > > +#if __STDC_VERSION__ - 0 < 199901L > > +/* > > + * Git is in a testing period for mandatory C99 support in the compiler. If > > + * your compiler is reasonably recent, you can try to enable C99 support (or, > > + * for MSVC, C11 support). If you encounter a problem and can't enable C99 > > + * support with your compiler and don't have access to one with this support, > > + * such as GCC or Clang, you can remove this #if directive, but please report > > + * the details of your system to git@vger.kernel.org. > > + */ > > +#error "Required C99 support is in a test phase. Please see git-compat-util.h for more details." > > You don't need to encapsulate the #error message in double quotes. Technically, I believe in this case you are correct. The C standard specifies this as pp-tokens, which means one or more preprocessing tokens, and from my brief overview of the draft standard, it appears that this meets that definition. (I could be wrong, though.) _However_, there are some cases where quoting is required, such as when apostrophes appear, and although we don't have that case here, there are some compilers which are very strict about what they do or don't allow in an #error statement, or which are just broken, and as such, in my experience, it is safer and more portable to always quote it. I definitely don't want us to have the problem that we break an otherwise functional compiler by causing it to choke on the #error directive it doesn't need to execute. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 262 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support 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 3:16 ` Eric Sunshine @ 2021-11-22 11:47 ` Johannes Schindelin 2 siblings, 0 replies; 20+ messages in thread From: Johannes Schindelin @ 2021-11-22 11:47 UTC (permalink / raw) To: brian m. carlson; +Cc: git Hi brian, On Sun, 14 Nov 2021, brian m. carlson wrote: > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt > index fd1399c440..91e8525fa9 100644 > --- a/contrib/buildsystems/CMakeLists.txt > +++ b/contrib/buildsystems/CMakeLists.txt > @@ -208,7 +208,7 @@ endif() > if(CMAKE_C_COMPILER_ID STREQUAL "MSVC") > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}) > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}) > - add_compile_options(/MP) > + add_compile_options(/MP /std:c11) > endif() > > #default behaviour If we do this, we also need the following patch, to ensure that `FLEX_ARRAY` is once again defined in a way that is acceptable for MS Visual C: -- snipsnap -- commit 9043470c19170643d1f74d6767a0df5d72e6c35c Author: Johannes Schindelin <Johannes.Schindelin@gmx.de> Date: Mon Nov 22 12:39:40 2021 +0100 fixup??? git-compat-util: add a test balloon for C99 support This seems to be required to define `FLEX_ARRAY` in a manner that MSVC in C11 mode accepts. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> diff --git a/git-compat-util.h b/git-compat-util.h index cba8ad260043..fcde3588172f 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -45,7 +45,7 @@ /* * See if our compiler is known to support flexible array members. */ -#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) && (!defined(__SUNPRO_C) || (__SUNPRO_C > 0x580)) +#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) && !defined(_MSC_VER) && (!defined(__SUNPRO_C) || (__SUNPRO_C > 0x580)) # define FLEX_ARRAY /* empty */ #elif defined(__GNUC__) # if (__GNUC__ >= 3) ^ permalink raw reply related [flat|nested] 20+ messages in thread
end of thread, other threads:[~2021-11-24 15:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20211114211622.1465981-1-sandals@crustytoothpaste.net> [not found] ` <20211114211622.1465981-2-sandals@crustytoothpaste.net> 2021-11-16 10:30 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 support Johannes Schindelin 2021-11-17 8:29 ` Junio C Hamano 2021-11-22 11:44 ` Johannes Schindelin 2021-11-22 13:05 ` Ævar Arnfjörð Bjarmason 2021-11-22 17:27 ` Junio C Hamano 2021-11-22 17:52 ` Carlo Arenas 2021-11-22 18:58 ` Junio C Hamano 2021-11-22 20:52 ` Junio C Hamano 2021-11-22 22:03 ` [PATCH 1/1] git-compat-util: add a test balloon for C99 supporty Johannes Schindelin 2021-11-22 22:10 ` Junio C Hamano 2021-11-22 22:22 ` Carlo Arenas 2021-11-23 12:32 ` Johannes Schindelin 2021-11-23 20:17 ` Junio C Hamano 2021-11-24 15:10 ` brian m. carlson 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
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).