{"thread":{"id":"56897","subject":"[PATCH 0/1] Add a test balloon for C99","startedAt":"2021-11-14T21:26:57Z","lastAt":"2021-12-02T17:38:19Z","messageCount":32,"participants":["brian m. carlson","Ævar Arnfjörð Bjarmason","Eric Sunshine","Junio C Hamano","Jeff King","Phillip Wood","Carlo Arenas","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"441099","messageId":"20211114212437.1466695-1-sandals@crustytoothpaste.net","threadId":"56897","inReplyTo":null,"subject":"[PATCH 0/1] Add a test balloon for C99","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-14T21:24:36Z","receivedAt":"2021-11-14T21:26:57Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The C99 standard, more formally known as ISO/IEC 9899:1999, was, as its\nname suggests, was ratified in 1999, more than 20 years ago[0]. It has\na variety of nice features, including loop variable initialization, that\nare available to most modern programmers.\n\nIn fact, POSIX 1003.1-2001 and the Single Unix Specification version 3,\nmade its use mandatory through the c99 command. As a practical matter,\nall known Unix systems which receive security support have support for\nthese standards or their successors, POSIX 1003.1-2018 and the Single\nUnix Specification version 4, and as such, we can safely assume support\nfor C99 there.\n\nUnfortunately, Microsoft for many years refused[1] to support C99 in\nMSVC, and still does not officially do so. However, they recently added\nsupport for C11 and C17, which are sufficient for modern programming.\nThese require a newer version of MSVC, including an updated SDK. The\nSDK update is available for download free of charge, and most public CI\nsystems have support for both the updated MSVC and the SDK update.\n\nEven for users who would like to target an older version of Windows,\nsuch as the no longer supported Windows 7, GCC and Clang are available.\nThe LLVM suite, including Clang, is available pre-compiled for download\nfree of charge. Using a different compiler is specifically proposed by\nMicrosoft staff[1] as a solution for users who wish to build modern\nprograms for MSVC versions which do not support modern C.\n\nAs such, we can assume that Git can be safely compiled with C99 or C11\nsupport on all operating systems which receive security support, and\neven some which do not. Our CI confirms that this series passes all\ntests. Let's introduce a test balloon which checks for this support and\nfails with an error message if it is absent.\n\n[0] The reader will note that there are people working professionally in\nthis industry who were not yet born at the time C99 was ratified. Thus,\nthis occurred quite a long time ago indeed.\n[1] https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/\n\nbrian m. carlson (1):\n git-compat-util: add a test balloon for C99 support\n\n Makefile | 4 ++--\n contrib/buildsystems/CMakeLists.txt | 3 +--\n git-compat-util.h | 12 ++++++++++++\n 3 files changed, 15 insertions(+), 4 deletions(-)\n\n"},{"id":"441100","messageId":"20211114212437.1466695-2-sandals@crustytoothpaste.net","threadId":"56897","inReplyTo":"20211114212437.1466695-1-sandals@crustytoothpaste.net","subject":"[PATCH 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-14T21:24:37Z","receivedAt":"2021-11-14T21:27:01Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The C99 standard was released in January 1999, now 22 years ago. It\nprovides a variety of useful features, including variadic arguments for\nmacros, declarations after statements, variable length arrays, and a\nwide variety of other useful features, many of which we already use.\n\nWe'd like to take advantage of these features, but we want to be\ncautious. As far as we know, all major compilers now support C99 or a\nlater C standard, such as C11 or C17. POSIX has required C99 support as\na requirement for the 2001 revision, so we can safely assume any POSIX\nsystem which we are interested in supporting has C99.\n\nEven MSVC, long a holdout against modern C, now supports both C11 and\nC17 with an appropriate update. Moreover, even if people are using an\nolder version of MSVC on these systems, they will generally need some\nimplementation of the standard Unix utilities for the testsuite, and GNU\ncoreutils, the most common option, has required C99 since 2009.\nTherefore, we can safely assume that a suitable version of GCC or clang\nis available to users even if their version of MSVC is not sufficiently\ncapable.\n\nLet's add a test balloon to git-compat-util.h to see if anyone is using\nan older compiler. We'll add a comment telling people how to enable\nthis functionality on GCC and Clang, even though modern versions of both\nwill automatically do the right thing, and ask people still experiencing\na problem to report that to us on the list.\n\nNote that C89 compilers don't provide the __STDC_VERSION__ macro, so we\nuse a well-known hack of using \"- 0\". On compilers with this macro, it\ndoesn't change the value, and on C89 compilers, the macro will be\nreplaced with nothing, and our value will be 0.\n\nSparse is also updated with a reference to the gnu99 standard, without\nwhich it defaults to C89.\n\nUpdate the cmake configuration to require C11 for MSVC. We do this\nbecause this will make MSVC to use C11, since it does not explicitly\nsupport C99. We do this with a compiler options because setting the\nC_STANDARD option does not work in our CI on MSVC and at the moment, we\ndon't want to require C11 for Unix compilers.\n\nSigned-off-by: brian m. carlson \n---\n Makefile | 4 ++--\n contrib/buildsystems/CMakeLists.txt | 3 +--\n git-compat-util.h | 12 ++++++++++++\n 3 files changed, 15 insertions(+), 4 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 12be39ac49..22d9e67542 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1204,7 +1204,7 @@ endif\n # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n # tweaked by config.* below as well as the command-line, both of\n # which'll override these defaults.\n-CFLAGS = -g -O2 -Wall\n+CFLAGS = -g -O2 -Wall -std=gnu99\n LDFLAGS =\n CC_LD_DYNPATH = -Wl,-rpath,\n BASIC_CFLAGS = -I.\n@@ -1215,7 +1215,7 @@ ARFLAGS = rcs\n PTHREAD_CFLAGS =\n \n # For the 'sparse' target\n-SPARSE_FLAGS ?=\n+SPARSE_FLAGS ?= -std=gnu99\n SP_EXTRA_FLAGS = -Wno-universal-initializer\n \n # For informing GIT-BUILD-OPTIONS of the SANITIZE=leak target\ndiff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\nindex fd1399c440..91e8525fa9 100644\n--- a/contrib/buildsystems/CMakeLists.txt\n+++ b/contrib/buildsystems/CMakeLists.txt\n@@ -208,7 +208,7 @@ endif()\n if(CMAKE_C_COMPILER_ID STREQUAL \"MSVC\")\n \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})\n \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})\n-\tadd_compile_options(/MP)\n+\tadd_compile_options(/MP /std:c11)\n endif()\n \n #default behaviour\n@@ -600,7 +600,6 @@ endif()\n list(REMOVE_DUPLICATES excluded_progs)\n list(REMOVE_DUPLICATES PROGRAMS_BUILT)\n \n-\n foreach(p ${excluded_progs})\n \tlist(APPEND EXCLUSION_PROGS --exclude-program ${p} )\n endforeach()\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex d70ce14286..6d995bdc0f 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -1,6 +1,18 @@\n #ifndef GIT_COMPAT_UTIL_H\n #define GIT_COMPAT_UTIL_H\n \n+#if __STDC_VERSION__ - 0 < 199901L\n+/*\n+ * Git is in a testing period for mandatory C99 support in the compiler. If\n+ * your compiler is reasonably recent, you can try to enable C99 support (or,\n+ * for MSVC, C11 support). If you encounter a problem and can't enable C99\n+ * support with your compiler and don't have access to one with this support,\n+ * such as GCC or Clang, you can remove this #if directive, but please report\n+ * the details of your system to git@vger.kernel.org.\n+ */\n+#error \"Required C99 support is in a test phase. Please see git-compat-util.h for more details.\"\n+#endif\n+\n #ifdef USE_MSVC_CRTDBG\n /*\n * For these to work they must appear very early in each\n"},{"id":"441101","messageId":"YZGC868o77qo8j8/@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"20211114212437.1466695-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 0/1] Add a test balloon for C99","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-14T21:43:15Z","receivedAt":"2021-11-14T21:43:31Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-14 at 21:24:36, brian m. carlson wrote:\n> brian m. carlson (1):\n> git-compat-util: add a test balloon for C99 support\n> \n> Makefile | 4 ++--\n> contrib/buildsystems/CMakeLists.txt | 3 +--\n> git-compat-util.h | 12 ++++++++++++\n> 3 files changed, 15 insertions(+), 4 deletions(-)\n\nNote that vger has decided to firewall my old MX, so I've resent this\nthrough a new one. If you received a CC on this, it's a different\nemail.\n\nThis should be fixed for the future.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441105","messageId":"211115.86v90urz21.gmgdl@evledraar.gmail.com","threadId":"56897","inReplyTo":"20211114212437.1466695-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-15T01:14:42Z","receivedAt":"2021-11-15T01:24:27Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Nov 14 2021, brian m. carlson wrote:\n\n> The C99 standard was released in January 1999, now 22 years ago. It\n> provides a variety of useful features, including variadic arguments for\n> macros, declarations after statements, variable length arrays, and a\n> wide variety of other useful features, many of which we already use.\n>\n> We'd like to take advantage of these features, but we want to be\n> cautious. As far as we know, all major compilers now support C99 or a\n> later C standard, such as C11 or C17. POSIX has required C99 support as\n> a requirement for the 2001 revision, so we can safely assume any POSIX\n> system which we are interested in supporting has C99.\n\nI like this direction.\n\n> Sparse is also updated with a reference to the gnu99 standard, without\n> which it defaults to C89.\n\nDo we really need it in SPARSE_FLAGS though...\n\n> @@ -1204,7 +1204,7 @@ endif\n> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n> # tweaked by config.* below as well as the command-line, both of\n> # which'll override these defaults.\n> -CFLAGS = -g -O2 -Wall\n> +CFLAGS = -g -O2 -Wall -std=gnu99\n> LDFLAGS =\n> CC_LD_DYNPATH = -Wl,-rpath,\n> BASIC_CFLAGS = -I.\n> @@ -1215,7 +1215,7 @@ ARFLAGS = rcs\n> PTHREAD_CFLAGS =\n\nSince $(CFLAGS) ends up in:\n\n ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS)\n\n...\n\n> # For the 'sparse' target\n> -SPARSE_FLAGS ?=\n> +SPARSE_FLAGS ?= -std=gnu99\n> SP_EXTRA_FLAGS = -Wno-universal-initializer\n\n... and this will be used for this rule:\n\n$(SP_OBJ): %.sp: %.c %.o\n $(QUIET_SP)cgcc -no-compile $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) \\\n -Wsparse-error \\\n $(SPARSE_FLAGS) $(SP_EXTRA_FLAGS) $< [...]\n\nI.e. unless it needs to be later on the command-line the $(ALL_CFLAGS)\nshould put it there already.\n\nAlso (and this pre-dates this patch) it's unfortunate that CFLAGS is a\nmixed bag of compiler tweaking and \"mandatory\" flags. I think the below\nwould be a better approach, particurly since our own config.mak.uname\nwill override CFLAGS in some cases, and probably everyone who works on\ngit to any degree has a local config.mak which sets it to something\nalready.\n\nBut why gnu99 and not c99?\n\ndiff --git a/Makefile b/Makefile\nindex 12be39ac497..7470d627165 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1204,10 +1204,14 @@ endif\n # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n # tweaked by config.* below as well as the command-line, both of\n # which'll override these defaults.\n+#\n+# The MANDATORY_CFLAGS can be similarly overridden, but really\n+# shouldn't.\n CFLAGS = -g -O2 -Wall\n LDFLAGS =\n CC_LD_DYNPATH = -Wl,-rpath,\n-BASIC_CFLAGS = -I.\n+BASIC_CFLAGS =\n+MANDATORY_CFLAGS = -I. -std=gnu99\n BASIC_LDFLAGS =\n \n # library flags\n@@ -1249,7 +1253,7 @@ ALL_COMMANDS_TO_INSTALL += git-upload-archive$(X)\n ALL_COMMANDS_TO_INSTALL += git-upload-pack$(X)\n endif\n \n-ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS)\n+ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(MANDATORY_CFLAGS)\n ALL_LDFLAGS = $(LDFLAGS)\n \n comma := ,\n"},{"id":"441106","messageId":"YZG9wF56unj7eYhl@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"211115.86v90urz21.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-15T01:54:08Z","receivedAt":"2021-11-15T02:03:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-15 at 01:14:42, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Sun, Nov 14 2021, brian m. carlson wrote:\n> \n> > The C99 standard was released in January 1999, now 22 years ago. It\n> > provides a variety of useful features, including variadic arguments for\n> > macros, declarations after statements, variable length arrays, and a\n> > wide variety of other useful features, many of which we already use.\n> >\n> > We'd like to take advantage of these features, but we want to be\n> > cautious. As far as we know, all major compilers now support C99 or a\n> > later C standard, such as C11 or C17. POSIX has required C99 support as\n> > a requirement for the 2001 revision, so we can safely assume any POSIX\n> > system which we are interested in supporting has C99.\n> \n> I like this direction.\n\nI felt like a test balloon would go over better than a wholesale\nchangeover. I feel confident we can make this change, and we may even\nin the not too distant future be able to switch to C11.\n\n> > Sparse is also updated with a reference to the gnu99 standard, without\n> > which it defaults to C89.\n> \n> Do we really need it in SPARSE_FLAGS though...\n> \n> > @@ -1204,7 +1204,7 @@ endif\n> > # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n> > # tweaked by config.* below as well as the command-line, both of\n> > # which'll override these defaults.\n> > -CFLAGS = -g -O2 -Wall\n> > +CFLAGS = -g -O2 -Wall -std=gnu99\n> > LDFLAGS =\n> > CC_LD_DYNPATH = -Wl,-rpath,\n> > BASIC_CFLAGS = -I.\n> > @@ -1215,7 +1215,7 @@ ARFLAGS = rcs\n> > PTHREAD_CFLAGS =\n> \n> Since $(CFLAGS) ends up in:\n> \n> ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS)\n> \n> ...\n> \n> > # For the 'sparse' target\n> > -SPARSE_FLAGS ?=\n> > +SPARSE_FLAGS ?= -std=gnu99\n> > SP_EXTRA_FLAGS = -Wno-universal-initializer\n> \n> ... and this will be used for this rule:\n> \n> $(SP_OBJ): %.sp: %.c %.o\n> $(QUIET_SP)cgcc -no-compile $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) \\\n> -Wsparse-error \\\n> $(SPARSE_FLAGS) $(SP_EXTRA_FLAGS) $< [...]\n> \n> I.e. unless it needs to be later on the command-line the $(ALL_CFLAGS)\n> should put it there already.\n\nI added it to SPARSE_FLAGS before adding it into CFLAGS, so I can look\ninto dropping it from the former.\n\n> Also (and this pre-dates this patch) it's unfortunate that CFLAGS is a\n> mixed bag of compiler tweaking and \"mandatory\" flags. I think the below\n> would be a better approach, particurly since our own config.mak.uname\n> will override CFLAGS in some cases, and probably everyone who works on\n> git to any degree has a local config.mak which sets it to something\n> already.\n\nWe don't want to do this, because some people are using other compilers\n(i.e., neither GCC nor clang) that need different options. We\ndefinitely do want them to be able to override these values as\nnecessary. I believe config.mak.uname does this in some cases for\ncertain Unix systems.\n\n> But why gnu99 and not c99?\n\nI'll explain in the commit message in a reroll, but essentially, because\nwe do in some case use GNUisms when we're working with GCC. Right now\nthose are mostly limited to providing C99 features on C89, but I'd like\nto leave the opportunity open for us to do this in the future.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441107","messageId":"CAPig+cTAfOor11SDWG0N-eeZZ=4hsmkMVAdcmiiJ+jXz3BAQVQ@mail.gmail.com","threadId":"56897","inReplyTo":"20211114212437.1466695-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-11-15T03:16:02Z","receivedAt":"2021-11-15T03:17:28Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Nov 14, 2021 at 4:27 PM brian m. carlson\n wrote:\n> +#if __STDC_VERSION__ - 0 < 199901L\n> +/*\n> + * Git is in a testing period for mandatory C99 support in the compiler. If\n> + * your compiler is reasonably recent, you can try to enable C99 support (or,\n> + * for MSVC, C11 support). If you encounter a problem and can't enable C99\n> + * support with your compiler and don't have access to one with this support,\n> + * such as GCC or Clang, you can remove this #if directive, but please report\n> + * the details of your system to git@vger.kernel.org.\n> + */\n> +#error \"Required C99 support is in a test phase. Please see git-compat-util.h for more details.\"\n\nYou don't need to encapsulate the #error message in double quotes.\n"},{"id":"441115","messageId":"xmqqy25pj43a.fsf@gitster.g","threadId":"56897","inReplyTo":"20211114212437.1466695-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 0/1] Add a test balloon for C99","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-15T07:00:25Z","receivedAt":"2021-11-15T07:00:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> Even for users who would like to target an older version of Windows,\n> such as the no longer supported Windows 7, GCC and Clang are available.\n> The LLVM suite, including Clang, is available pre-compiled for download\n> free of charge. Using a different compiler is specifically proposed by\n> Microsoft staff[1] as a solution for users who wish to build modern\n> programs for MSVC versions which do not support modern C.\n>\n> As such, we can assume that Git can be safely compiled with C99 or C11\n> support on all operating systems which receive security support, and\n> even some which do not. Our CI confirms that this series passes all\n> tests. Let's introduce a test balloon which checks for this support and\n> fails with an error message if it is absent.\n\nI do not have much against adopting nicer C99 language features in\nprinciple, but I hope that we are not becoming too Linux centric\nwith \"other than Linux, as long as Windows is OK in some form,\neverything is peachy\" mentality.\n\nIf there is a rogue implementation that claims to do C99 with\nSTDC_VERSION without properly supporting some language constructs we\ncare about, that would be bad. That is why I tend to prefer the\napproach we have taken so far, validating selected features we care\nabout one by one with pointed weather balloon tests, over \"the\ncompiler says it supports that version, so we trust them\".\n\nPerhaps we can do this, and a more pointed \"break compilers without\nvariable decl in for() loop\" change, at the same time. After the\nlatter turns out to be noise free, we can update CodingGuidelines.\n\nEven when we clear C99 as the whole, I'd be hesitant to allow\ncertain things from the language (not because compilers do not grok\nthem, but purely from style and readability point of view). For\nexample, -Wdecl-after-statement is a good discipline to follow even\nif your compiler allows them.\n\nThanks.\n\n\n Documentation/CodingGuidelines | 7 ++++---\n 1 file changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines\nindex 45465bc0c9..5c32b29949 100644\n--- c/Documentation/CodingGuidelines\n+++ w/Documentation/CodingGuidelines\n@@ -205,15 +205,16 @@ For C programs:\n . since mid 2017 with 512f41cf, we have been using designated\n initializers for array (e.g. \"int array[10] = { [5] = 2 }\").\n \n+ . since early 2022 with YYYYYYY, we have been using variable\n+ declaration in the for loop (e.g. \"for (int i = 0; i < 10;\n+ i++)\").\n+\n These used to be forbidden, but we have not heard any breakage\n report, and they are assumed to be safe.\n \n - Variables have to be declared at the beginning of the block, before\n the first statement (i.e. -Wdeclaration-after-statement).\n \n- - Declaring a variable in the for loop \"for (int i = 0; i < 10; i++)\"\n- is still not allowed in this codebase.\n-\n - NULL pointers shall be written as NULL, not as 0.\n \n - When declaring pointers, the star sides with the variable\n"},{"id":"441204","messageId":"YZLh/1xkxRGDn76u@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"xmqqy25pj43a.fsf@gitster.g","subject":"Re: [PATCH 0/1] Add a test balloon for C99","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-15T22:41:03Z","receivedAt":"2021-11-15T23:43:06Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-15 at 07:00:25, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > Even for users who would like to target an older version of Windows,\n> > such as the no longer supported Windows 7, GCC and Clang are available.\n> > The LLVM suite, including Clang, is available pre-compiled for download\n> > free of charge. Using a different compiler is specifically proposed by\n> > Microsoft staff[1] as a solution for users who wish to build modern\n> > programs for MSVC versions which do not support modern C.\n> >\n> > As such, we can assume that Git can be safely compiled with C99 or C11\n> > support on all operating systems which receive security support, and\n> > even some which do not. Our CI confirms that this series passes all\n> > tests. Let's introduce a test balloon which checks for this support and\n> > fails with an error message if it is absent.\n> \n> I do not have much against adopting nicer C99 language features in\n> principle, but I hope that we are not becoming too Linux centric\n> with \"other than Linux, as long as Windows is OK in some form,\n> everything is peachy\" mentality.\n\nIt's definitely not my goal to exclude Windows here. I'm pretty sure\nevery major Unix platform will handle this fine, and an up to date\nMSVC will also handle this fine.\n\nBecause compiling Git for Windows is a lot of work (not due to any\nfailing of that project or its members, just the fact that it requires a\nlot of components to be assembled, including a full POSIX environment),\nit's not very likely we're going to see a lot of people doing it, since\nalmost all Windows users are going to be using the regular releases.\nIt's also likely that they're going to be using some automated CI system\nwhich will likely support a recent version of the compiler.\n\nHowever, we have in the past heard screaming from people who want to\nsupport old versions of Windows, so my point here is that there are\noptions if they can't use MSVC for any reason and those options are\neasy, accessible, and free of charge. I should point out that we\nalready require people on non-Linux Unix systems to install GNU make and\npossibly also a shell (if theirs doesn't support the local keyword), so\ninstalling suitable tooling to build Git isn't without precedent.\n\n> If there is a rogue implementation that claims to do C99 with\n> STDC_VERSION without properly supporting some language constructs we\n> care about, that would be bad. That is why I tend to prefer the\n> approach we have taken so far, validating selected features we care\n> about one by one with pointed weather balloon tests, over \"the\n> compiler says it supports that version, so we trust them\".\n\nI think this is going to be unlikely. People can and do expect to rely\non __STDC_VERSION__ working properly, and it's likely any compiler which\nlacked those features has long been fixed.\n\n> Perhaps we can do this, and a more pointed \"break compilers without\n> variable decl in for() loop\" change, at the same time. After the\n> latter turns out to be noise free, we can update CodingGuidelines.\n\nAs I mentioned in another thread, we'll need a patch like this first to\nenable proper handling for older compilers, but I think that should be\nfine on top.\n\n> Even when we clear C99 as the whole, I'd be hesitant to allow\n> certain things from the language (not because compilers do not grok\n> them, but purely from style and readability point of view). For\n> example, -Wdecl-after-statement is a good discipline to follow even\n> if your compiler allows them.\n\nI think specifically -Wdecl-after-statement depends on the situation.\nThere are many cases where it's less error prone or easier to read if\nthe variable is declared immediately before it's used.\n\nRegardless, I don't think we need to decide this now.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441223","messageId":"20211116021241.1565740-1-sandals@crustytoothpaste.net","threadId":"56897","inReplyTo":"20211114212437.1466695-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 0/1] Add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-16T02:12:40Z","receivedAt":"2021-11-16T02:16:36Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"There seems to be a decent amount of interest in moving to C99 as our\nbase level of C support due to the many features it provides. Let's add\na test balloon to make sure we haven't accidentally excluded any\nsystems.\n\nChanges from v1:\n* Don't modify SPARSE_FLAGS since it's unnecessary.\n* Improve commit message to explain why we use -std=gnu99.\n\nbrian m. carlson (1):\n git-compat-util: add a test balloon for C99 support\n\n Makefile | 2 +-\n contrib/buildsystems/CMakeLists.txt | 2 +-\n git-compat-util.h | 12 ++++++++++++\n 3 files changed, 14 insertions(+), 2 deletions(-)\n\n"},{"id":"441240","messageId":"YZMPMFiQmtgfp15H@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"CAPig+cTAfOor11SDWG0N-eeZZ=4hsmkMVAdcmiiJ+jXz3BAQVQ@mail.gmail.com","subject":"Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-16T01:53:52Z","receivedAt":"2021-11-16T04:48:09Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-15 at 03:16:02, Eric Sunshine wrote:\n> On Sun, Nov 14, 2021 at 4:27 PM brian m. carlson\n> wrote:\n> > +#if __STDC_VERSION__ - 0 < 199901L\n> > +/*\n> > + * Git is in a testing period for mandatory C99 support in the compiler. If\n> > + * your compiler is reasonably recent, you can try to enable C99 support (or,\n> > + * for MSVC, C11 support). If you encounter a problem and can't enable C99\n> > + * support with your compiler and don't have access to one with this support,\n> > + * such as GCC or Clang, you can remove this #if directive, but please report\n> > + * the details of your system to git@vger.kernel.org.\n> > + */\n> > +#error \"Required C99 support is in a test phase. Please see git-compat-util.h for more details.\"\n> \n> You don't need to encapsulate the #error message in double quotes.\n\nTechnically, I believe in this case you are correct. The C standard\nspecifies this as pp-tokens, which means one or more preprocessing\ntokens, and from my brief overview of the draft standard, it appears\nthat this meets that definition. (I could be wrong, though.)\n\n_However_, there are some cases where quoting is required, such as when\napostrophes appear, and although we don't have that case here, there are\nsome compilers which are very strict about what they do or don't allow\nin an #error statement, or which are just broken, and as such, in my\nexperience, it is safer and more portable to always quote it. I\ndefinitely don't want us to have the problem that we break an otherwise\nfunctional compiler by causing it to choke on the #error directive it\ndoesn't need to execute.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441241","messageId":"20211116021241.1565740-2-sandals@crustytoothpaste.net","threadId":"56897","inReplyTo":"20211116021241.1565740-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-16T02:12:41Z","receivedAt":"2021-11-16T05:10:47Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The C99 standard was released in January 1999, now 22 years ago. It\nprovides a variety of useful features, including variadic arguments for\nmacros, declarations after statements, variable length arrays, and a\nwide variety of other useful features, many of which we already use.\n\nWe'd like to take advantage of these features, but we want to be\ncautious. As far as we know, all major compilers now support C99 or a\nlater C standard, such as C11 or C17. POSIX has required C99 support as\na requirement for the 2001 revision, so we can safely assume any POSIX\nsystem which we are interested in supporting has C99.\n\nEven MSVC, long a holdout against modern C, now supports both C11 and\nC17 with an appropriate update. Moreover, even if people are using an\nolder version of MSVC on these systems, they will generally need some\nimplementation of the standard Unix utilities for the testsuite, and GNU\ncoreutils, the most common option, has required C99 since 2009.\nTherefore, we can safely assume that a suitable version of GCC or clang\nis available to users even if their version of MSVC is not sufficiently\ncapable.\n\nLet's add a test balloon to git-compat-util.h to see if anyone is using\nan older compiler. We'll add a comment telling people how to enable\nthis functionality on GCC and Clang, even though modern versions of both\nwill automatically do the right thing, and ask people still experiencing\na problem to report that to us on the list.\n\nNote that C89 compilers don't provide the __STDC_VERSION__ macro, so we\nuse a well-known hack of using \"- 0\". On compilers with this macro, it\ndoesn't change the value, and on C89 compilers, the macro will be\nreplaced with nothing, and our value will be 0.\n\nWe explicitly request the gnu99 style because we've traditionally taken\nadvantage of some GCC- and clang-specific extensions when available and\nwe'd like to retain the ability to do that, especially now that we're\nbuilding with -pedantic in developer mode. Older compilers may in fact\nsupport C99 just fine, but default to C89 without an option, so the\noption is necessary. Allow it to be overridden by the user or\nconfig.mak.uname to ensure that people using other compilers can make it\nwork.\n\nUpdate the cmake configuration to require C11 for MSVC. We do this\nbecause this will make MSVC to use C11, since it does not explicitly\nsupport C99. We do this with a compiler options because setting the\nC_STANDARD option does not work in our CI on MSVC and at the moment, we\ndon't want to require C11 for Unix compilers.\n\nSigned-off-by: brian m. carlson \n---\n Makefile | 2 +-\n contrib/buildsystems/CMakeLists.txt | 2 +-\n git-compat-util.h | 12 ++++++++++++\n 3 files changed, 14 insertions(+), 2 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 12be39ac49..893d533d22 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1204,7 +1204,7 @@ endif\n # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n # tweaked by config.* below as well as the command-line, both of\n # which'll override these defaults.\n-CFLAGS = -g -O2 -Wall\n+CFLAGS = -g -O2 -Wall -std=gnu99\n LDFLAGS =\n CC_LD_DYNPATH = -Wl,-rpath,\n BASIC_CFLAGS = -I.\ndiff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\nindex fd1399c440..07b6c5494b 100644\n--- a/contrib/buildsystems/CMakeLists.txt\n+++ b/contrib/buildsystems/CMakeLists.txt\n@@ -208,7 +208,7 @@ endif()\n if(CMAKE_C_COMPILER_ID STREQUAL \"MSVC\")\n \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})\n \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})\n-\tadd_compile_options(/MP)\n+\tadd_compile_options(/MP /std:c11)\n endif()\n \n #default behaviour\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex d70ce14286..6d995bdc0f 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -1,6 +1,18 @@\n #ifndef GIT_COMPAT_UTIL_H\n #define GIT_COMPAT_UTIL_H\n \n+#if __STDC_VERSION__ - 0 < 199901L\n+/*\n+ * Git is in a testing period for mandatory C99 support in the compiler. If\n+ * your compiler is reasonably recent, you can try to enable C99 support (or,\n+ * for MSVC, C11 support). If you encounter a problem and can't enable C99\n+ * support with your compiler and don't have access to one with this support,\n+ * such as GCC or Clang, you can remove this #if directive, but please report\n+ * the details of your system to git@vger.kernel.org.\n+ */\n+#error \"Required C99 support is in a test phase. Please see git-compat-util.h for more details.\"\n+#endif\n+\n #ifdef USE_MSVC_CRTDBG\n /*\n * For these to work they must appear very early in each\n"},{"id":"441321","messageId":"YZOh370ZMMqSADUE@coredump.intra.peff.net","threadId":"56897","inReplyTo":"20211116021241.1565740-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-16T12:19:43Z","receivedAt":"2021-11-16T12:21:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 16, 2021 at 02:12:41AM +0000, brian m. carlson wrote:\n\n> The C99 standard was released in January 1999, now 22 years ago. It\n> provides a variety of useful features, including variadic arguments for\n> macros, declarations after statements, variable length arrays, and a\n> wide variety of other useful features, many of which we already use.\n\nI like the idea of being able to assume C99. And I know this list is\njust \"here are some things we could do\". But I'd like to express caution\nover variable length arrays. We've already had problems with alloca()\ncausing stack exhaustion, and VLAs are basically the same thing. And the\nworst part is there's no way to recover; you just get a segfault.\n\n> Let's add a test balloon to git-compat-util.h to see if anyone is using\n> an older compiler. We'll add a comment telling people how to enable\n> this functionality on GCC and Clang, even though modern versions of both\n> will automatically do the right thing, and ask people still experiencing\n> a problem to report that to us on the list.\n> \n> Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we\n> use a well-known hack of using \"- 0\". On compilers with this macro, it\n> doesn't change the value, and on C89 compilers, the macro will be\n> replaced with nothing, and our value will be 0.\n\nThis part makes sense to me. The macro check will complain if any\ncompiler isn't C99. But this hunk seems like it is going to cause\nheadaches:\n\n> diff --git a/Makefile b/Makefile\n> index 12be39ac49..893d533d22 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -1204,7 +1204,7 @@ endif\n> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n> # tweaked by config.* below as well as the command-line, both of\n> # which'll override these defaults.\n> -CFLAGS = -g -O2 -Wall\n> +CFLAGS = -g -O2 -Wall -std=gnu99\n> LDFLAGS =\n> CC_LD_DYNPATH = -Wl,-rpath,\n> BASIC_CFLAGS = -I.\n\nDo most compilers understand -std=gnu99? It seems like we're breaking\nthe out-of-the-box build for everything that isn't gcc or clang.\n\nI understand that older versions of gcc (prior to 5.1.0, from my\ndigging) default to gnu89, and so they would be broken _without_ this.\nSo it is a tradeoff one way or the other. But somehow this seems\nbackwards to me. We should assume that modern compilers support C99 out\nof the box, and put the burden on older ones to trigger C99 support in\nwhatever non-portable way they need.\n\nI also checked clang, and it looks like it has defaulted to gnu11 since\nclang-7 (I'm not sure about clang-6; its documentation wasn't clear).\n\n-Peff\n"},{"id":"441324","messageId":"211116.86pmr0p82k.gmgdl@evledraar.gmail.com","threadId":"56897","inReplyTo":"YZOh370ZMMqSADUE@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-16T12:54:27Z","receivedAt":"2021-11-16T13:02:32Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Nov 16 2021, Jeff King wrote:\n\n> On Tue, Nov 16, 2021 at 02:12:41AM +0000, brian m. carlson wrote:\n[...]\n>> diff --git a/Makefile b/Makefile\n>> index 12be39ac49..893d533d22 100644\n>> --- a/Makefile\n>> +++ b/Makefile\n>> @@ -1204,7 +1204,7 @@ endif\n>> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n>> # tweaked by config.* below as well as the command-line, both of\n>> # which'll override these defaults.\n>> -CFLAGS = -g -O2 -Wall\n>> +CFLAGS = -g -O2 -Wall -std=gnu99\n>> LDFLAGS =\n>> CC_LD_DYNPATH = -Wl,-rpath,\n>> BASIC_CFLAGS = -I.\n>\n> Do most compilers understand -std=gnu99? It seems like we're breaking\n> the out-of-the-box build for everything that isn't gcc or clang.\n>\n> I understand that older versions of gcc (prior to 5.1.0, from my\n> digging) default to gnu89, and so they would be broken _without_ this.\n> So it is a tradeoff one way or the other. But somehow this seems\n> backwards to me. We should assume that modern compilers support C99 out\n> of the box, and put the burden on older ones to trigger C99 support in\n> whatever non-portable way they need.\n>\n> I also checked clang, and it looks like it has defaulted to gnu11 since\n> clang-7 (I'm not sure about clang-6; its documentation wasn't clear).\n\nYes, this seems like something we'd really want to feed to\n\"detect-compiler\" after extracting it out of config.mak.dev.\n\nAnd as you note it's not only that older or non-gcc non-clang compilers\nmay not understand this at all, but are we getting worse behavior on\nmodern versions of those two because they're forced into some 20 year\nold C99 standard mode, instead of the current preferred default?\n\nIf we do go for this there's also the additional breakage I mentioned\nupthread of th [1], and which I think I wasn't clear enough about. I.e. if we do:\n\n CFLAGS = -O2 -g -std=whatever\n\nAnd then in config.mak.uname do e.g.:\n\n CFLAGS = -g -O0 -Winline\n\nWe'll override the -std=whatever, but just wanted to overrride the -O2.\n\nThis came up in another context recently (Carlo had series to hack in\nthis area), but I think we shouldn't add anything new to CFLAGS. Let's\ninstead add a new variable like BASIC_CFLAGS, so in this case\nCFLAGS_C_STANDARD or whatever, and then later in the file:\n\n -ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS)\n +ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_C_STANDARD)\n\nBut IMO this whole thing of trying to make this work on every compiler\netc. just isn't worth it.\n\nLet's just start using C99 features, and if anyone's compiler breaks on\nsomething like CentOS 6 document that they'll need to tweak a flag\nsomewhere. We already know that works for all the other C99 features we\nhave, there seems to just be this one exception of the ancient GCC\nversion in this particular case.\n\n1. https://lore.kernel.org/git/YZG9wF56unj7eYhl@camp.crustytoothpaste.net/\n"},{"id":"441328","messageId":"YZPGKHYE/9km1rH5@coredump.intra.peff.net","threadId":"56897","inReplyTo":"211116.86pmr0p82k.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-16T14:54:32Z","receivedAt":"2021-11-16T14:54:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 16, 2021 at 01:54:27PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> But IMO this whole thing of trying to make this work on every compiler\n> etc. just isn't worth it.\n> \n> Let's just start using C99 features, and if anyone's compiler breaks on\n> something like CentOS 6 document that they'll need to tweak a flag\n> somewhere. We already know that works for all the other C99 features we\n> have, there seems to just be this one exception of the ancient GCC\n> version in this particular case.\n\nYeah, I definitely agree with this sentiment.\n\n-Peff\n"},{"id":"441349","messageId":"xmqqpmqzapqn.fsf@gitster.g","threadId":"56897","inReplyTo":"YZLh/1xkxRGDn76u@camp.crustytoothpaste.net","subject":"Re: [PATCH 0/1] Add a test balloon for C99","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-16T19:02:08Z","receivedAt":"2021-11-16T19:02:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2021-11-15 at 07:00:25, Junio C Hamano wrote:\n>> \"brian m. carlson\" writes:\n>> \n>> > Even for users who would like to target an older version of Windows,\n>> > such as the no longer supported Windows 7, GCC and Clang are available.\n>> > The LLVM suite, including Clang, is available pre-compiled for download\n>> > free of charge. Using a different compiler is specifically proposed by\n>> > Microsoft staff[1] as a solution for users who wish to build modern\n>> > programs for MSVC versions which do not support modern C.\n>> >\n>> > As such, we can assume that Git can be safely compiled with C99 or C11\n>> > support on all operating systems which receive security support, and\n>> > even some which do not. Our CI confirms that this series passes all\n>> > tests. Let's introduce a test balloon which checks for this support and\n>> > fails with an error message if it is absent.\n>> \n>> I do not have much against adopting nicer C99 language features in\n>> principle, but I hope that we are not becoming too Linux centric\n>> with \"other than Linux, as long as Windows is OK in some form,\n>> everything is peachy\" mentality.\n>\n> It's definitely not my goal to exclude Windows here. I'm pretty sure\n> every major Unix platform will handle this fine, and an up to date\n> MSVC will also handle this fine.\n>\n> Because compiling Git for Windows is a lot of work (not due to any\n> failing of that project or its members, just the fact that it requires a\n> lot of components to be assembled, including a full POSIX environment),\n> it's not very likely we're going to see a lot of people doing it, since\n> almost all Windows users are going to be using the regular releases.\n> It's also likely that they're going to be using some automated CI system\n> which will likely support a recent version of the compiler.\n>\n> However, we have in the past heard screaming from people who want to\n> support old versions of Windows, so my point here is that there are\n> options if they can't use MSVC for any reason and those options are\n> easy, accessible, and free of charge. I should point out that we\n> already require people on non-Linux Unix systems to install GNU make and\n> possibly also a shell (if theirs doesn't support the local keyword), so\n> installing suitable tooling to build Git isn't without precedent.\n\nWindows does not need me to worry about them---they can fend for\nthemselves. I cannot tell if the original discussion behind the\npatch considered the current situation in non-mac BSD land (which I\nam not familiar with), or even less common platforms like NonStop.\n"},{"id":"441356","messageId":"a1961817-27d4-5be5-3b6f-231b77d3b916@gmail.com","threadId":"56897","inReplyTo":"YZOh370ZMMqSADUE@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-11-16T19:44:21Z","receivedAt":"2021-11-16T19:44:42Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 16/11/2021 12:19, Jeff King wrote:\n> On Tue, Nov 16, 2021 at 02:12:41AM +0000, brian m. carlson wrote:\n> \n>> The C99 standard was released in January 1999, now 22 years ago. It\n>> provides a variety of useful features, including variadic arguments for\n>> macros, declarations after statements, variable length arrays, and a\n>> wide variety of other useful features, many of which we already use.\n> \n> I like the idea of being able to assume C99. And I know this list is\n> just \"here are some things we could do\". But I'd like to express caution\n> over variable length arrays. We've already had problems with alloca()\n> causing stack exhaustion, and VLAs are basically the same thing. And the\n> worst part is there's no way to recover; you just get a segfault.\n\nI agree with this, also C11 and later make variable length array support \nan optional compiler feature which is another reason not to rely on them.\n\nBest Wishes\n\nPhillip\n\n>> Let's add a test balloon to git-compat-util.h to see if anyone is using\n>> an older compiler. We'll add a comment telling people how to enable\n>> this functionality on GCC and Clang, even though modern versions of both\n>> will automatically do the right thing, and ask people still experiencing\n>> a problem to report that to us on the list.\n>>\n>> Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we\n>> use a well-known hack of using \"- 0\". On compilers with this macro, it\n>> doesn't change the value, and on C89 compilers, the macro will be\n>> replaced with nothing, and our value will be 0.\n> \n> This part makes sense to me. The macro check will complain if any\n> compiler isn't C99. But this hunk seems like it is going to cause\n> headaches:\n> \n>> diff --git a/Makefile b/Makefile\n>> index 12be39ac49..893d533d22 100644\n>> --- a/Makefile\n>> +++ b/Makefile\n>> @@ -1204,7 +1204,7 @@ endif\n>> # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n>> # tweaked by config.* below as well as the command-line, both of\n>> # which'll override these defaults.\n>> -CFLAGS = -g -O2 -Wall\n>> +CFLAGS = -g -O2 -Wall -std=gnu99\n>> LDFLAGS =\n>> CC_LD_DYNPATH = -Wl,-rpath,\n>> BASIC_CFLAGS = -I.\n> \n> Do most compilers understand -std=gnu99? It seems like we're breaking\n> the out-of-the-box build for everything that isn't gcc or clang.\n> \n> I understand that older versions of gcc (prior to 5.1.0, from my\n> digging) default to gnu89, and so they would be broken _without_ this.\n> So it is a tradeoff one way or the other. But somehow this seems\n> backwards to me. We should assume that modern compilers support C99 out\n> of the box, and put the burden on older ones to trigger C99 support in\n> whatever non-portable way they need.\n> \n> I also checked clang, and it looks like it has defaulted to gnu11 since\n> clang-7 (I'm not sure about clang-6; its documentation wasn't clear).\n> \n> -Peff\n> \n"},{"id":"441385","messageId":"YZRedzMSodOYjjPP@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"YZOh370ZMMqSADUE@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-17T01:44:23Z","receivedAt":"2021-11-17T01:44:26Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-16 at 12:19:43, Jeff King wrote:\n> On Tue, Nov 16, 2021 at 02:12:41AM +0000, brian m. carlson wrote:\n> \n> > The C99 standard was released in January 1999, now 22 years ago. It\n> > provides a variety of useful features, including variadic arguments for\n> > macros, declarations after statements, variable length arrays, and a\n> > wide variety of other useful features, many of which we already use.\n> \n> I like the idea of being able to assume C99. And I know this list is\n> just \"here are some things we could do\". But I'd like to express caution\n> over variable length arrays. We've already had problems with alloca()\n> causing stack exhaustion, and VLAs are basically the same thing. And the\n> worst part is there's no way to recover; you just get a segfault.\n\nSince it looks like I'll be doing a v3, I'll reroll without that.\n\n> > diff --git a/Makefile b/Makefile\n> > index 12be39ac49..893d533d22 100644\n> > --- a/Makefile\n> > +++ b/Makefile\n> > @@ -1204,7 +1204,7 @@ endif\n> > # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n> > # tweaked by config.* below as well as the command-line, both of\n> > # which'll override these defaults.\n> > -CFLAGS = -g -O2 -Wall\n> > +CFLAGS = -g -O2 -Wall -std=gnu99\n> > LDFLAGS =\n> > CC_LD_DYNPATH = -Wl,-rpath,\n> > BASIC_CFLAGS = -I.\n> \n> Do most compilers understand -std=gnu99? It seems like we're breaking\n> the out-of-the-box build for everything that isn't gcc or clang.\n\nI'm pretty sure -Wall is GCC- and clang-specific, as is -Wl,-rpath, so I\nthink we've already crossed that bridge. There are places in\nconfig.mak.uname where they're specifically overridden for that reason.\n\n-std=gnu99 (or -std=c99) is absolutely required for sparse, though,\nsince it defaults to C89 (at least in CI).\n\n> I understand that older versions of gcc (prior to 5.1.0, from my\n> digging) default to gnu89, and so they would be broken _without_ this.\n> So it is a tradeoff one way or the other. But somehow this seems\n> backwards to me. We should assume that modern compilers support C99 out\n> of the box, and put the burden on older ones to trigger C99 support in\n> whatever non-portable way they need.\n\nWe'll have to adjust the CI job that builds with GCC 4.8, but I can do\nthat. I just am not eager to hear complaints from people that it\ndoesn't work out of the box, especially since CentOS 7 is going to hit\nthis case.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441387","messageId":"YZRgL5YYm7JCQQQp@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"xmqqpmqzapqn.fsf@gitster.g","subject":"Re: [PATCH 0/1] Add a test balloon for C99","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-17T01:51:43Z","receivedAt":"2021-11-17T01:51:49Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-16 at 19:02:08, Junio C Hamano wrote:\n> Windows does not need me to worry about them---they can fend for\n> themselves. I cannot tell if the original discussion behind the\n> patch considered the current situation in non-mac BSD land (which I\n> am not familiar with), or even less common platforms like NonStop.\n\nOh, I did full well consider BSD land. They are generally up on the\nlatest standards, and I would even say that most proprietary Unix\nsystems are also far enough along from what I know of them. I do try\nspecifically to support BSD systems and consider their needs to the best\nof my abilities.\n\nAs for NonStop, I checked, and it already forces C99 mode because we use\nenough features, like inline, that C89 doesn't support and so it needs\nto do that already.\n\nI do appreciate you looking out for them, though.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441393","messageId":"YZRurUdyB/cGL6Y3@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"YZPGKHYE/9km1rH5@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-17T02:53:33Z","receivedAt":"2021-11-17T02:53:37Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-16 at 14:54:32, Jeff King wrote:\n> On Tue, Nov 16, 2021 at 01:54:27PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> \n> > But IMO this whole thing of trying to make this work on every compiler\n> > etc. just isn't worth it.\n> > \n> > Let's just start using C99 features, and if anyone's compiler breaks on\n> > something like CentOS 6 document that they'll need to tweak a flag\n> > somewhere. We already know that works for all the other C99 features we\n> > have, there seems to just be this one exception of the ancient GCC\n> > version in this particular case.\n> \n> Yeah, I definitely agree with this sentiment.\n\nUnfortunately, we cannot do this without some sort of patch because our\nCI will be broken. I'm fine if we want to drop GCC 4.8, but we need to\nbe explicit about that or we need to add flags to make it work. We also\nneed at least something to make Windows work. Dscho will not be happy\nif we just leave it broken.\n\nSo I think some version of this patch or something similar needs to be\nadopted. I'll try to get a v3 out relatively soon that fixes these\nissues and drops -std=gnu99 from CFLAGS, which seems to be the approach\npeople are most desirous of.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441394","messageId":"YZRvwfIaAODilQc3@coredump.intra.peff.net","threadId":"56897","inReplyTo":"YZRedzMSodOYjjPP@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-17T02:58:09Z","receivedAt":"2021-11-17T02:58:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 17, 2021 at 01:44:23AM +0000, brian m. carlson wrote:\n\n> > Do most compilers understand -std=gnu99? It seems like we're breaking\n> > the out-of-the-box build for everything that isn't gcc or clang.\n> \n> I'm pretty sure -Wall is GCC- and clang-specific, as is -Wl,-rpath, so I\n> think we've already crossed that bridge. There are places in\n> config.mak.uname where they're specifically overridden for that reason.\n\nThat's a good point. I guess we don't really have good data on how many\npeople will be (newly) affected either way.\n\n> > I understand that older versions of gcc (prior to 5.1.0, from my\n> > digging) default to gnu89, and so they would be broken _without_ this.\n> > So it is a tradeoff one way or the other. But somehow this seems\n> > backwards to me. We should assume that modern compilers support C99 out\n> > of the box, and put the burden on older ones to trigger C99 support in\n> > whatever non-portable way they need.\n> \n> We'll have to adjust the CI job that builds with GCC 4.8, but I can do\n> that. I just am not eager to hear complaints from people that it\n> doesn't work out of the box, especially since CentOS 7 is going to hit\n> this case.\n\nNor am I. I wonder if there's a way we can make it work out of the box\neverywhere. Using detect-compiler more widely would be one way to do\nthat, though that's a bigger change to the Makefile in general. I kind\nof wonder if we could just assume in config.mak.uname that Linux will\nalways have a compiler that understands -std=gnu99.\n\n-Peff\n"},{"id":"441396","messageId":"YZRwpekXlilhOEx4@coredump.intra.peff.net","threadId":"56897","inReplyTo":"YZRurUdyB/cGL6Y3@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-17T03:01:57Z","receivedAt":"2021-11-17T03:02:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 17, 2021 at 02:53:33AM +0000, brian m. carlson wrote:\n\n> On 2021-11-16 at 14:54:32, Jeff King wrote:\n> > On Tue, Nov 16, 2021 at 01:54:27PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> > \n> > > But IMO this whole thing of trying to make this work on every compiler\n> > > etc. just isn't worth it.\n> > > \n> > > Let's just start using C99 features, and if anyone's compiler breaks on\n> > > something like CentOS 6 document that they'll need to tweak a flag\n> > > somewhere. We already know that works for all the other C99 features we\n> > > have, there seems to just be this one exception of the ancient GCC\n> > > version in this particular case.\n> > \n> > Yeah, I definitely agree with this sentiment.\n> \n> Unfortunately, we cannot do this without some sort of patch because our\n> CI will be broken. I'm fine if we want to drop GCC 4.8, but we need to\n> be explicit about that or we need to add flags to make it work. We also\n> need at least something to make Windows work. Dscho will not be happy\n> if we just leave it broken.\n\nYes, but I'm not at all worried about breaking our CI. That's just a\npatch away from fixing. I'm much more worried about confused users\nbuilding from source, because helping them is more difficult to scale.\n\nMy thinking was that breaking older compilers was preferable to breaking\nnon-gnu ones, because at least old ones go away eventually. But your\nother email makes me wonder if those non-GNU ones may already be\noverriding CFLAGS.\n\nStill, if we can come up with a solution that breaks neither (with some\nlight auto-detection or heuristics in the Makefile), that could be the\nbest of both worlds.\n\n-Peff\n"},{"id":"441417","messageId":"xmqqwnl72mm1.fsf@gitster.g","threadId":"56897","inReplyTo":"YZPGKHYE/9km1rH5@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-17T08:49:10Z","receivedAt":"2021-11-17T08:49:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Nov 16, 2021 at 01:54:27PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>\n>> But IMO this whole thing of trying to make this work on every compiler\n>> etc. just isn't worth it.\n>> \n>> Let's just start using C99 features, and if anyone's compiler breaks on\n>> something like CentOS 6 document that they'll need to tweak a flag\n>> somewhere. We already know that works for all the other C99 features we\n>> have, there seems to just be this one exception of the ancient GCC\n>> version in this particular case.\n>\n> Yeah, I definitely agree with this sentiment.\n\n+1, provided that we are not saying that \"we will start using any\nrandom C99 features\" without limit. I do appreciate the way the\nprevious efforts were conducted, to start with small test balloons\nthat can easily be backed out and leaving it there for sufficiently\nlong time.\n"},{"id":"441532","messageId":"YZWNumAlsek9Gi22@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"YZRwpekXlilhOEx4@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-17T23:18:18Z","receivedAt":"2021-11-17T23:18:22Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-17 at 03:01:57, Jeff King wrote:\n> Yes, but I'm not at all worried about breaking our CI. That's just a\n> patch away from fixing. I'm much more worried about confused users\n> building from source, because helping them is more difficult to scale.\n\nThat's one of the reasons I had proposed the current patch, because it\npukes in a very noticeable way with directives on where to look to\ncontinue. Just using C99 features means that Git breaks in a very\nsubtle way where the user compiling may not be familiar with C and may\nnot know how to fix it otherwise. For example, my previous employer\nships Git, but many of the folks who are doing the package updates are\nnot C programmers.\n\n> My thinking was that breaking older compilers was preferable to breaking\n> non-gnu ones, because at least old ones go away eventually. But your\n> other email makes me wonder if those non-GNU ones may already be\n> overriding CFLAGS.\n\nOur only problem platform, as far as I can tell, is RHEL/CentOS 7. That\nuses GCC 4.8, and even Ubuntu 18.04 ships with GCC 7.\n\n> Still, if we can come up with a solution that breaks neither (with some\n> light auto-detection or heuristics in the Makefile), that could be the\n> best of both worlds.\n\nI can move COMPILER_FEATURES out of config.mak.dev and into Makefile so\nthat we can make use of it. We'll need to depend on GCC 6 for this\nbecause we lack a way to distinguish 5.1 (which should work) from 5.0\n(which will not).\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"441538","messageId":"CAPUEspg=ef9xSiYsVKHfo7zogExeMwL3gMnN_bq1QcKv0fnNng@mail.gmail.com","threadId":"56897","inReplyTo":"YZWNumAlsek9Gi22@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2021-11-17T23:45:39Z","receivedAt":"2021-11-17T23:46:05Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Wed, Nov 17, 2021 at 3:18 PM brian m. carlson\n wrote:\n>\n> On 2021-11-17 at 03:01:57, Jeff King wrote:\n> > My thinking was that breaking older compilers was preferable to breaking\n> > non-gnu ones, because at least old ones go away eventually. But your\n> > other email makes me wonder if those non-GNU ones may already be\n> > overriding CFLAGS.\n>\n> Our only problem platform, as far as I can tell, is RHEL/CentOS 7. That\n> uses GCC 4.8, and even Ubuntu 18.04 ships with GCC 7.\n\nThere are several odd BSD platforms that are still stuck in pre-GPLv3\ngcc (AKA gcc 4.2.1) like OpenBSD Alpha, hppa, landisk (and maybe also\nSPARC64 which is tier1) and that will need the same, there is indeed\nalso luna88k that uses an even older gcc but hopefully will be able to\nwork if it understands enough C99 and can be told to use it by this\nflag.\n\n> > Still, if we can come up with a solution that breaks neither (with some\n> > light auto-detection or heuristics in the Makefile), that could be the\n> > best of both worlds.\n>\n> I can move COMPILER_FEATURES out of config.mak.dev and into Makefile so\n> that we can make use of it. We'll need to depend on GCC 6 for this\n> because we lack a way to distinguish 5.1 (which should work) from 5.0\n> (which will not).\n\n5.0 works AFAIK, is anything older than 5 than does not as reported[1]\nbefore, but it won't be still a good fit, since it only works for gcc\nand clang AS-IS.\n\nCarlo\n\n[1] https://lore.kernel.org/git/CAPUEsphnCvK+RZ+h30ZarA1zo9yZ=ndEBrcAbKGf4W92j647vA@mail.gmail.com/\n"},{"id":"441557","messageId":"211118.86lf1m5h1y.gmgdl@evledraar.gmail.com","threadId":"56897","inReplyTo":"CAPUEspg=ef9xSiYsVKHfo7zogExeMwL3gMnN_bq1QcKv0fnNng@mail.gmail.com","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-18T02:26:58Z","receivedAt":"2021-11-18T02:33:19Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Nov 17 2021, Carlo Arenas wrote:\n\n> On Wed, Nov 17, 2021 at 3:18 PM brian m. carlson\n> wrote:\n>>\n>> On 2021-11-17 at 03:01:57, Jeff King wrote:\n>> > My thinking was that breaking older compilers was preferable to breaking\n>> > non-gnu ones, because at least old ones go away eventually. But your\n>> > other email makes me wonder if those non-GNU ones may already be\n>> > overriding CFLAGS.\n>>\n>> Our only problem platform, as far as I can tell, is RHEL/CentOS 7. That\n>> uses GCC 4.8, and even Ubuntu 18.04 ships with GCC 7.\n>\n> There are several odd BSD platforms that are still stuck in pre-GPLv3\n> gcc (AKA gcc 4.2.1) like OpenBSD Alpha, hppa, landisk (and maybe also\n> SPARC64 which is tier1) and that will need the same, there is indeed\n> also luna88k that uses an even older gcc but hopefully will be able to\n> work if it understands enough C99 and can be told to use it by this\n> flag.\n>\n>> > Still, if we can come up with a solution that breaks neither (with some\n>> > light auto-detection or heuristics in the Makefile), that could be the\n>> > best of both worlds.\n>>\n>> I can move COMPILER_FEATURES out of config.mak.dev and into Makefile so\n>> that we can make use of it. We'll need to depend on GCC 6 for this\n>> because we lack a way to distinguish 5.1 (which should work) from 5.0\n>> (which will not).\n>\n> 5.0 works AFAIK, is anything older than 5 than does not as reported[1]\n> before, but it won't be still a good fit, since it only works for gcc\n> and clang AS-IS.\n>\n> Carlo\n>\n> [1] https://lore.kernel.org/git/CAPUEsphnCvK+RZ+h30ZarA1zo9yZ=ndEBrcAbKGf4W92j647vA@mail.gmail.com/\n\nRather than moving around COMPILER_FEATURES etc. we can just compile a C\nprogram as part of our Makefile auto-configuration. See the direction\nsuggested in:\nhttps://lore.kernel.org/git/87bl6aypke.fsf@evledraar.gmail.com/\n\nThat example is ad-hoc, but the right way to do this is:\n\n 1. Stick a C program somewhere, maybe git-autoconf/compiler.c \n 2. (Try to) Compile that unconditionally\n 3. Emit its output to a generated file that we then \"include\", which\n likewise if it fails indicate that in something the Makefile can\n \"include\".\n\nSince we set up that file-based dependency relationship we'll only do\nthat auto-detection on the first build.\n\nThis is really much simpler than fiddling with the version parsing\nshellscript, i.e. we can just compile a program with -std=c99 or\nwhatever and see if it works, and if it does we stick that flag in\nCFLAGS or equivalent.\n"},{"id":"441652","messageId":"xmqqy25lwa86.fsf@gitster.g","threadId":"56897","inReplyTo":"YZWNumAlsek9Gi22@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-18T19:10:49Z","receivedAt":"2021-11-18T19:10:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2021-11-17 at 03:01:57, Jeff King wrote:\n>> Yes, but I'm not at all worried about breaking our CI. That's just a\n>> patch away from fixing. I'm much more worried about confused users\n>> building from source, because helping them is more difficult to scale.\n>\n> That's one of the reasons I had proposed the current patch, because it\n> pukes in a very noticeable way with directives on where to look to\n> continue. Just using C99 features means that Git breaks in a very\n> subtle way where the user compiling may not be familiar with C and may\n> not know how to fix it otherwise. For example, my previous employer\n> ships Git, but many of the folks who are doing the package updates are\n> not C programmers.\n\nI wonder if this would work, then.\n\n Makefile | 3 ++-\n revision.c | 3 ++-\n 2 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git c/Makefile w/Makefile\nindex 201437e9d4..454118d86b 100644\n--- c/Makefile\n+++ w/Makefile\n@@ -1218,7 +1218,8 @@ endif\n # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be\n # tweaked by config.* below as well as the command-line, both of\n # which'll override these defaults.\n-CFLAGS = -g -O2 -Wall -std=gnu99\n+# Older versions of GCC may require adding \"-std=gnu99\" at the end.\n+CFLAGS = -g -O2 -Wall\n LDFLAGS =\n CC_LD_DYNPATH = -Wl,-rpath,\n BASIC_CFLAGS = -I.\ndiff --git c/revision.c w/revision.c\nindex 78c1ceea7b..5390a479b3 100644\n--- c/revision.c\n+++ w/revision.c\n@@ -49,7 +49,8 @@ void show_object_with_name(FILE *out, struct object *obj, const char *name)\n \t * This \"for (const char *p = ...\" is made as a first step towards\n \t * making use of such declarations elsewhere in our codebase. If\n \t * it causes compilation problems on your platform, please report\n-\t * it to the Git mailing list at git@vger.kernel.org.\n+\t * it to the Git mailing list at git@vger.kernel.org. In the meantime,\n+\t * adding -std=gnu99 to CFLAGS may help if you are with older GCC.\n \t */\n \tfor (const char *p = name; *p && *p != '\\n'; p++)\n \t\tfputc(*p, out);\n"},{"id":"441928","messageId":"nycvar.QRO.7.76.6.2111221245460.63@tvgsbejvaqbjf.bet","threadId":"56897","inReplyTo":"20211114212437.1466695-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-11-22T11:47:28Z","receivedAt":"2021-11-22T11:47:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Sun, 14 Nov 2021, brian m. carlson wrote:\n\n> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\n> index fd1399c440..91e8525fa9 100644\n> --- a/contrib/buildsystems/CMakeLists.txt\n> +++ b/contrib/buildsystems/CMakeLists.txt\n> @@ -208,7 +208,7 @@ endif()\n> if(CMAKE_C_COMPILER_ID STREQUAL \"MSVC\")\n> \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})\n> \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})\n> -\tadd_compile_options(/MP)\n> +\tadd_compile_options(/MP /std:c11)\n> endif()\n>\n> #default behaviour\n\nIf we do this, we also need the following patch, to ensure that\n`FLEX_ARRAY` is once again defined in a way that is acceptable for MS\nVisual C:\n\n-- snipsnap --\ncommit 9043470c19170643d1f74d6767a0df5d72e6c35c\nAuthor: Johannes Schindelin \nDate: Mon Nov 22 12:39:40 2021 +0100\n\n fixup??? git-compat-util: add a test balloon for C99 support\n\n This seems to be required to define `FLEX_ARRAY` in a manner that MSVC\n in C11 mode accepts.\n\n Signed-off-by: Johannes Schindelin \n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex cba8ad260043..fcde3588172f 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -45,7 +45,7 @@\n /*\n * See if our compiler is known to support flexible array members.\n */\n-#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) && (!defined(__SUNPRO_C) || (__SUNPRO_C > 0x580))\n+#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) && !defined(_MSC_VER) && (!defined(__SUNPRO_C) || (__SUNPRO_C > 0x580))\n # define FLEX_ARRAY /* empty */\n #elif defined(__GNUC__)\n # if (__GNUC__ >= 3)\n"},{"id":"442681","messageId":"211130.86o861cqnu.gmgdl@evledraar.gmail.com","threadId":"56897","inReplyTo":"20211114212437.1466695-1-sandals@crustytoothpaste.net","subject":"Microsoft's C language policy (was: [PATCH 0/1] Add a test balloon for C99)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T20:43:15Z","receivedAt":"2021-11-30T20:52:28Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Nov 14 2021, brian m. carlson wrote:\n\n[Replying to this tidbit in the v1 CL, which isn't in the V2 one]\n\n> Unfortunately, Microsoft for many years refused[1] to support C99 in\n> MSVC, and still does not officially do so. However, they recently added\n> support for C11 and C17, which are sufficient for modern programming.\n> These require a newer version of MSVC, including an updated SDK. The\n> SDK update is available for download free of charge, and most public CI\n> systems have support for both the updated MSVC and the SDK update.\n>\n> Even for users who would like to target an older version of Windows,\n> such as the no longer supported Windows 7, GCC and Clang are available.\n> The LLVM suite, including Clang, is available pre-compiled for download\n> free of charge. Using a different compiler is specifically proposed by\n> Microsoft staff[1] as a solution for users who wish to build modern\n> programs for MSVC versions which do not support modern C.\n>\n> As such, we can assume that Git can be safely compiled with C99 or C11\n> support on all operating systems which receive security support, and\n> even some which do not. Our CI confirms that this series passes all\n> tests. Let's introduce a test balloon which checks for this support and\n> fails with an error message if it is absent.\n>\n> [0] The reader will note that there are people working professionally in\n> this industry who were not yet born at the time C99 was ratified. Thus,\n> this occurred quite a long time ago indeed.\n> [1] https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/\n\nI hadn't seen that blog post before I'd read it when going over your\nseries. I'd assumed that Microsoft was just dragging their feed on C\nlanguage support, but that post indicates (from what seems to be as\nofficial of a source as anyone's going to get) that they're intending to\nnot support C at all, but just some pseudo-C that happens to be a\nconvenient subset of C++.\n\nHowever that post is from 2012, and you indicate that they've since\nadded (full?) support for C11 and C17.\n\nSo is this \"policy\" of supporting some arbitrary subset of C++ at all\ncurrent as far as MSVC today goes?\n\nAside: I just remembered we had a (seemingly abandoned) effort to get git's sources to\ncompile with a C++ compiler[1], which would be another possible way\nforward to using more modern C features that happened to overlap with\nC++. Another one would be some sort of coccinelle-powered refactoring or\nother source pre-processing...\n\n1. https://lore.kernel.org/git/20180129223728.30569-1-bmwill@google.com/\n"},{"id":"442714","messageId":"YaanjQgqb6riZGh8@camp.crustytoothpaste.net","threadId":"56897","inReplyTo":"211130.86o861cqnu.gmgdl@evledraar.gmail.com","subject":"Re: Microsoft's C language policy (was: [PATCH 0/1] Add a test balloon for C99)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-30T22:37:01Z","receivedAt":"2021-11-30T22:37:18Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-30 at 20:43:15, Ævar Arnfjörð Bjarmason wrote:\n> I hadn't seen that blog post before I'd read it when going over your\n> series. I'd assumed that Microsoft was just dragging their feed on C\n> language support, but that post indicates (from what seems to be as\n> official of a source as anyone's going to get) that they're intending to\n> not support C at all, but just some pseudo-C that happens to be a\n> convenient subset of C++.\n> \n> However that post is from 2012, and you indicate that they've since\n> added (full?) support for C11 and C17.\n>\n> So is this \"policy\" of supporting some arbitrary subset of C++ at all\n> current as far as MSVC today goes?\n\nNo, it is not. MSVC should have full C11 and C17 support, at least\naccording to the documentation I've seen. They seem to have changed\ntheir mind (maybe the Windows kernel developers complained).\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"442731","messageId":"20211201014050.38002-2-sandals@crustytoothpaste.net","threadId":"56897","inReplyTo":"20211201014050.38002-1-sandals@crustytoothpaste.net","subject":"[PATCH v3 1/1] git-compat-util: add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-12-01T01:40:50Z","receivedAt":"2021-12-01T01:42:31Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The C99 standard was released in January 1999, now 22 years ago. It\nprovides a variety of useful features, including variadic arguments for\nmacros, declarations after statements, designated initializers, and a\nwide variety of other useful features, many of which we already use.\n\nWe'd like to take advantage of these features, but we want to be\ncautious. As far as we know, all major compilers now support C99 or a\nlater C standard, such as C11 or C17. POSIX has required C99 support as\na requirement for the 2001 revision, so we can safely assume any POSIX\nsystem which we are interested in supporting has C99.\n\nEven MSVC, long a holdout against modern C, now supports both C11 and\nC17 with an appropriate update. Moreover, even if people are using an\nolder version of MSVC on these systems, they will generally need some\nimplementation of the standard Unix utilities for the testsuite, and GNU\ncoreutils, the most common option, has required C99 since 2009.\nTherefore, we can safely assume that a suitable version of GCC or clang\nis available to users even if their version of MSVC is not sufficiently\ncapable.\n\nLet's add a test balloon to git-compat-util.h to see if anyone is using\nan older compiler. We'll add a comment telling people how to enable\nthis functionality on GCC and Clang, even though modern versions of both\nwill automatically do the right thing, and ask people still experiencing\na problem to report that to us on the list.\n\nNote that C89 compilers don't provide the __STDC_VERSION__ macro, so we\nuse a well-known hack of using \"- 0\". On compilers with this macro, it\ndoesn't change the value, and on C89 compilers, the macro will be\nreplaced with nothing, and our value will be 0.\n\nFor sparse, we explicitly request the gnu99 style because we've\ntraditionally taken advantage of some GCC- and clang-specific extensions\nwhen available and we'd like to retain the ability to do that. sparse\nalso defaults to C89 without it, so things will fail for us if we don't.\n\nUpdate the cmake configuration to require C11 for MSVC. We do this\nbecause this will make MSVC to use C11, since it does not explicitly\nsupport C99. We do this with a compiler options because setting the\nC_STANDARD option does not work in our CI on MSVC and at the moment, we\ndon't want to require C11 for Unix compilers.\n\nIn the Makefile, don't set any compiler flags for the compiler itself,\nsince on some systems, such as FreeBSD, we actually need C11, and asking\nfor C99 causes things to fail to compile. The error message should make\nit obvious what's going wrong and allow a user to set the appropriate\noption when building in the event they're using a Unix compiler that\ndoesn't support it by default.\n\nSigned-off-by: brian m. carlson \n---\n Makefile | 2 +-\n contrib/buildsystems/CMakeLists.txt | 2 +-\n git-compat-util.h | 13 +++++++++++++\n 3 files changed, 15 insertions(+), 2 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 12be39ac49..3d0ce6ddf6 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1215,7 +1215,7 @@ ARFLAGS = rcs\n PTHREAD_CFLAGS =\n \n # For the 'sparse' target\n-SPARSE_FLAGS ?=\n+SPARSE_FLAGS ?= -std=gnu99\n SP_EXTRA_FLAGS = -Wno-universal-initializer\n \n # For informing GIT-BUILD-OPTIONS of the SANITIZE=leak target\ndiff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\nindex fd1399c440..07b6c5494b 100644\n--- a/contrib/buildsystems/CMakeLists.txt\n+++ b/contrib/buildsystems/CMakeLists.txt\n@@ -208,7 +208,7 @@ endif()\n if(CMAKE_C_COMPILER_ID STREQUAL \"MSVC\")\n \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})\n \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})\n-\tadd_compile_options(/MP)\n+\tadd_compile_options(/MP /std:c11)\n endif()\n \n #default behaviour\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex d70ce14286..ffe70b570f 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -1,6 +1,19 @@\n #ifndef GIT_COMPAT_UTIL_H\n #define GIT_COMPAT_UTIL_H\n \n+#if __STDC_VERSION__ - 0 < 199901L\n+/*\n+ * Git is in a testing period for mandatory C99 support in the compiler. If\n+ * your compiler is reasonably recent, you can try to enable C99 support (or,\n+ * for MSVC, C11 support). If you encounter a problem and can't enable C99\n+ * support with your compiler (such as with \"-std=gnu99\") and don't have access\n+ * to one with this support, such as GCC or Clang, you can remove this #if\n+ * directive, but please report the details of your system to\n+ * git@vger.kernel.org.\n+ */\n+#error \"Required C99 support is in a test phase. Please see git-compat-util.h for more details.\"\n+#endif\n+\n #ifdef USE_MSVC_CRTDBG\n /*\n * For these to work they must appear very early in each\n"},{"id":"442732","messageId":"20211201014050.38002-1-sandals@crustytoothpaste.net","threadId":"56897","inReplyTo":"20211114212437.1466695-1-sandals@crustytoothpaste.net","subject":"[PATCH v3 0/1] Add a test balloon for C99 support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-12-01T01:40:49Z","receivedAt":"2021-12-01T01:42:31Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"There seems to be a decent amount of interest in moving to C99 as our\nbase level of C support due to the many features it provides. Let's add\na test balloon to make sure we haven't accidentally excluded any\nsystems.\n\nChanges from v2:\n* Avoid setting the main CFLAGS to avoid breaking FreeBSD.\n* Set SPARSE_FLAGS again since it's now necessary with the main CFLAGS\n not being set.\n* Add a mention of \"-std=gnu99\" to the comment.\nChanges from v1:\n* Don't modify SPARSE_FLAGS since it's unnecessary.\n* Improve commit message to explain why we use -std=gnu99.\n\nbrian m. carlson (1):\n git-compat-util: add a test balloon for C99 support\n\n Makefile | 2 +-\n contrib/buildsystems/CMakeLists.txt | 2 +-\n git-compat-util.h | 13 +++++++++++++\n 3 files changed, 15 insertions(+), 2 deletions(-)\n\n"},{"id":"442893","messageId":"nycvar.QRO.7.76.6.2112021836170.63@tvgsbejvaqbjf.bet","threadId":"56897","inReplyTo":"20211201014050.38002-2-sandals@crustytoothpaste.net","subject":"Re: [PATCH v3 1/1] git-compat-util: add a test balloon for C99 support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-12-02T17:38:03Z","receivedAt":"2021-12-02T17:38:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi brian,\n\nOn Wed, 1 Dec 2021, brian m. carlson wrote:\n\n> The C99 standard was released in January 1999, now 22 years ago. It\n> provides a variety of useful features, including variadic arguments for\n> macros, declarations after statements, designated initializers, and a\n> wide variety of other useful features, many of which we already use.\n>\n> We'd like to take advantage of these features, but we want to be\n> cautious. As far as we know, all major compilers now support C99 or a\n> later C standard, such as C11 or C17. POSIX has required C99 support as\n> a requirement for the 2001 revision, so we can safely assume any POSIX\n> system which we are interested in supporting has C99.\n>\n> Even MSVC, long a holdout against modern C, now supports both C11 and\n> C17 with an appropriate update. Moreover, even if people are using an\n> older version of MSVC on these systems, they will generally need some\n> implementation of the standard Unix utilities for the testsuite, and GNU\n> coreutils, the most common option, has required C99 since 2009.\n> Therefore, we can safely assume that a suitable version of GCC or clang\n> is available to users even if their version of MSVC is not sufficiently\n> capable.\n>\n> Let's add a test balloon to git-compat-util.h to see if anyone is using\n> an older compiler. We'll add a comment telling people how to enable\n> this functionality on GCC and Clang, even though modern versions of both\n> will automatically do the right thing, and ask people still experiencing\n> a problem to report that to us on the list.\n>\n> Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we\n> use a well-known hack of using \"- 0\". On compilers with this macro, it\n> doesn't change the value, and on C89 compilers, the macro will be\n> replaced with nothing, and our value will be 0.\n>\n> For sparse, we explicitly request the gnu99 style because we've\n> traditionally taken advantage of some GCC- and clang-specific extensions\n> when available and we'd like to retain the ability to do that. sparse\n> also defaults to C89 without it, so things will fail for us if we don't.\n\nI agree with this revision of the patch entirely, especially with this\nparagraph.\n\nIf there should crop up any Windows-specific issues, I will be glad to\nhave a look at them.\n\nThank you,\nDscho\n\n>\n> Update the cmake configuration to require C11 for MSVC. We do this\n> because this will make MSVC to use C11, since it does not explicitly\n> support C99. We do this with a compiler options because setting the\n> C_STANDARD option does not work in our CI on MSVC and at the moment, we\n> don't want to require C11 for Unix compilers.\n>\n> In the Makefile, don't set any compiler flags for the compiler itself,\n> since on some systems, such as FreeBSD, we actually need C11, and asking\n> for C99 causes things to fail to compile. The error message should make\n> it obvious what's going wrong and allow a user to set the appropriate\n> option when building in the event they're using a Unix compiler that\n> doesn't support it by default.\n>\n> Signed-off-by: brian m. carlson \n> ---\n> Makefile | 2 +-\n> contrib/buildsystems/CMakeLists.txt | 2 +-\n> git-compat-util.h | 13 +++++++++++++\n> 3 files changed, 15 insertions(+), 2 deletions(-)\n>\n> diff --git a/Makefile b/Makefile\n> index 12be39ac49..3d0ce6ddf6 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -1215,7 +1215,7 @@ ARFLAGS = rcs\n> PTHREAD_CFLAGS =\n>\n> # For the 'sparse' target\n> -SPARSE_FLAGS ?=\n> +SPARSE_FLAGS ?= -std=gnu99\n> SP_EXTRA_FLAGS = -Wno-universal-initializer\n>\n> # For informing GIT-BUILD-OPTIONS of the SANITIZE=leak target\n> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\n> index fd1399c440..07b6c5494b 100644\n> --- a/contrib/buildsystems/CMakeLists.txt\n> +++ b/contrib/buildsystems/CMakeLists.txt\n> @@ -208,7 +208,7 @@ endif()\n> if(CMAKE_C_COMPILER_ID STREQUAL \"MSVC\")\n> \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})\n> \tset(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})\n> -\tadd_compile_options(/MP)\n> +\tadd_compile_options(/MP /std:c11)\n> endif()\n>\n> #default behaviour\n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index d70ce14286..ffe70b570f 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -1,6 +1,19 @@\n> #ifndef GIT_COMPAT_UTIL_H\n> #define GIT_COMPAT_UTIL_H\n>\n> +#if __STDC_VERSION__ - 0 < 199901L\n> +/*\n> + * Git is in a testing period for mandatory C99 support in the compiler. If\n> + * your compiler is reasonably recent, you can try to enable C99 support (or,\n> + * for MSVC, C11 support). If you encounter a problem and can't enable C99\n> + * support with your compiler (such as with \"-std=gnu99\") and don't have access\n> + * to one with this support, such as GCC or Clang, you can remove this #if\n> + * directive, but please report the details of your system to\n> + * git@vger.kernel.org.\n> + */\n> +#error \"Required C99 support is in a test phase. Please see git-compat-util.h for more details.\"\n> +#endif\n> +\n> #ifdef USE_MSVC_CRTDBG\n> /*\n> * For these to work they must appear very early in each\n>\n"}]}