On 2021-11-15 at 07:00:25, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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 (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
