| Message ID | 20211114212437.1466695-1-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add a test balloon for C99 | expand |
On 2021-11-14 at 21:24:36, brian m. carlson wrote: > 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(-) Note that vger has decided to firewall my old MX, so I've resent this through a new one. If you received a CC on this, it's a different email. This should be fixed for the future.
"brian m. carlson" <sandals@crustytoothpaste.net> writes: > 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. I do not have much against adopting nicer C99 language features in principle, but I hope that we are not becoming too Linux centric with "other than Linux, as long as Windows is OK in some form, everything is peachy" mentality. If there is a rogue implementation that claims to do C99 with STDC_VERSION without properly supporting some language constructs we care about, that would be bad. That is why I tend to prefer the approach we have taken so far, validating selected features we care about one by one with pointed weather balloon tests, over "the compiler says it supports that version, so we trust them". Perhaps we can do this, and a more pointed "break compilers without variable decl in for() loop" change, at the same time. After the latter turns out to be noise free, we can update CodingGuidelines. Even when we clear C99 as the whole, I'd be hesitant to allow certain things from the language (not because compilers do not grok them, but purely from style and readability point of view). For example, -Wdecl-after-statement is a good discipline to follow even if your compiler allows them. Thanks. Documentation/CodingGuidelines | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines index 45465bc0c9..5c32b29949 100644 --- c/Documentation/CodingGuidelines +++ w/Documentation/CodingGuidelines @@ -205,15 +205,16 @@ For C programs: . since mid 2017 with 512f41cf, we have been using designated initializers for array (e.g. "int array[10] = { [5] = 2 }"). + . since early 2022 with YYYYYYY, we have been using variable + declaration in the for loop (e.g. "for (int i = 0; i < 10; + i++)"). + These used to be forbidden, but we have not heard any breakage report, and they are assumed to be safe. - Variables have to be declared at the beginning of the block, before the first statement (i.e. -Wdeclaration-after-statement). - - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)" - is still not allowed in this codebase. - - NULL pointers shall be written as NULL, not as 0. - When declaring pointers, the star sides with the variable
On 2021-11-15 at 07:00:25, Junio C Hamano wrote: > "brian m. carlson" <sandals@crustytoothpaste.net> writes: > > > 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. > > I do not have much against adopting nicer C99 language features in > principle, but I hope that we are not becoming too Linux centric > with "other than Linux, as long as Windows is OK in some form, > everything is peachy" mentality. It's definitely not my goal to exclude Windows here. I'm pretty sure every major Unix platform will handle this fine, and an up to date MSVC will also handle this fine. Because compiling Git for Windows is a lot of work (not due to any failing of that project or its members, just the fact that it requires a lot of components to be assembled, including a full POSIX environment), it's not very likely we're going to see a lot of people doing it, since almost all Windows users are going to be using the regular releases. It's also likely that they're going to be using some automated CI system which will likely support a recent version of the compiler. However, we have in the past heard screaming from people who want to support old versions of Windows, so my point here is that there are options if they can't use MSVC for any reason and those options are easy, accessible, and free of charge. I should point out that we already require people on non-Linux Unix systems to install GNU make and possibly also a shell (if theirs doesn't support the local keyword), so installing suitable tooling to build Git isn't without precedent. > If there is a rogue implementation that claims to do C99 with > STDC_VERSION without properly supporting some language constructs we > care about, that would be bad. That is why I tend to prefer the > approach we have taken so far, validating selected features we care > about one by one with pointed weather balloon tests, over "the > compiler says it supports that version, so we trust them". I think this is going to be unlikely. People can and do expect to rely on __STDC_VERSION__ working properly, and it's likely any compiler which lacked those features has long been fixed. > Perhaps we can do this, and a more pointed "break compilers without > variable decl in for() loop" change, at the same time. After the > latter turns out to be noise free, we can update CodingGuidelines. As I mentioned in another thread, we'll need a patch like this first to enable proper handling for older compilers, but I think that should be fine on top. > Even when we clear C99 as the whole, I'd be hesitant to allow > certain things from the language (not because compilers do not grok > them, but purely from style and readability point of view). For > example, -Wdecl-after-statement is a good discipline to follow even > if your compiler allows them. I think specifically -Wdecl-after-statement depends on the situation. There are many cases where it's less error prone or easier to read if the variable is declared immediately before it's used. Regardless, I don't think we need to decide this now.
"brian m. carlson" <sandals@crustytoothpaste.net> writes: > On 2021-11-15 at 07:00:25, Junio C Hamano wrote: >> "brian m. carlson" <sandals@crustytoothpaste.net> writes: >> >> > 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. >> >> I do not have much against adopting nicer C99 language features in >> principle, but I hope that we are not becoming too Linux centric >> with "other than Linux, as long as Windows is OK in some form, >> everything is peachy" mentality. > > It's definitely not my goal to exclude Windows here. I'm pretty sure > every major Unix platform will handle this fine, and an up to date > MSVC will also handle this fine. > > Because compiling Git for Windows is a lot of work (not due to any > failing of that project or its members, just the fact that it requires a > lot of components to be assembled, including a full POSIX environment), > it's not very likely we're going to see a lot of people doing it, since > almost all Windows users are going to be using the regular releases. > It's also likely that they're going to be using some automated CI system > which will likely support a recent version of the compiler. > > However, we have in the past heard screaming from people who want to > support old versions of Windows, so my point here is that there are > options if they can't use MSVC for any reason and those options are > easy, accessible, and free of charge. I should point out that we > already require people on non-Linux Unix systems to install GNU make and > possibly also a shell (if theirs doesn't support the local keyword), so > installing suitable tooling to build Git isn't without precedent. Windows does not need me to worry about them---they can fend for themselves. I cannot tell if the original discussion behind the patch considered the current situation in non-mac BSD land (which I am not familiar with), or even less common platforms like NonStop.
On 2021-11-16 at 19:02:08, Junio C Hamano wrote: > Windows does not need me to worry about them---they can fend for > themselves. I cannot tell if the original discussion behind the > patch considered the current situation in non-mac BSD land (which I > am not familiar with), or even less common platforms like NonStop. Oh, I did full well consider BSD land. They are generally up on the latest standards, and I would even say that most proprietary Unix systems are also far enough along from what I know of them. I do try specifically to support BSD systems and consider their needs to the best of my abilities. As for NonStop, I checked, and it already forces C99 mode because we use enough features, like inline, that C89 doesn't support and so it needs to do that already. I do appreciate you looking out for them, though.
On Sun, Nov 14 2021, brian m. carlson wrote: [Replying to this tidbit in the v1 CL, which isn't in the V2 one] > 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/ I hadn't seen that blog post before I'd read it when going over your series. I'd assumed that Microsoft was just dragging their feed on C language support, but that post indicates (from what seems to be as official of a source as anyone's going to get) that they're intending to not support C at all, but just some pseudo-C that happens to be a convenient subset of C++. However that post is from 2012, and you indicate that they've since added (full?) support for C11 and C17. So is this "policy" of supporting some arbitrary subset of C++ at all current as far as MSVC today goes? Aside: I just remembered we had a (seemingly abandoned) effort to get git's sources to compile with a C++ compiler[1], which would be another possible way forward to using more modern C features that happened to overlap with C++. Another one would be some sort of coccinelle-powered refactoring or other source pre-processing... 1. https://lore.kernel.org/git/20180129223728.30569-1-bmwill@google.com/
On 2021-11-30 at 20:43:15, Ævar Arnfjörð Bjarmason wrote: > I hadn't seen that blog post before I'd read it when going over your > series. I'd assumed that Microsoft was just dragging their feed on C > language support, but that post indicates (from what seems to be as > official of a source as anyone's going to get) that they're intending to > not support C at all, but just some pseudo-C that happens to be a > convenient subset of C++. > > However that post is from 2012, and you indicate that they've since > added (full?) support for C11 and C17. > > So is this "policy" of supporting some arbitrary subset of C++ at all > current as far as MSVC today goes? No, it is not. MSVC should have full C11 and C17 support, at least according to the documentation I've seen. They seem to have changed their mind (maybe the Windows kernel developers complained).