Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
A separate weather balloon for C99 as a whole was raised separately
in 7bc341e2 (git-compat-util: add a test balloon for C99 support,
2021-12-01). Hopefully, as we find out that all C99 features are OK
on all platforms we care about, we can stop probing the features we
want one-by-one like this
Unfortunately this really isn't the case at all, the norm is for
compilers to advertise that they support verison X of the standard via
these macros when they consider the support "good enough", but while
there's still a long list of unimplemented features before they're at
100% support (and most never fully get to 100%).
We also need to worry about the stdlib implementation, and not just the
compiler, see e.g. the %zu format and MinGW in the exchange at
https://lore.kernel.org/git/220318.86bky3cr8j.gmgdl@evledraar.gmail.com/
and
https://lore.kernel.org/git/a67e0fd8-4a14-16c9-9b57-3430440ef93c@gmail.com/;
But I think we're thoroughly past needing to worry about basic language
features in C99 such as these inline variable declarations.
Well, that makes it sound like the C99 weather balloon was almost
useless, doesn't it?
In any case, I'll strick the last paragraph from the final log
message, as the patch text itself is about one specific feature, and
not about deciding what our policy for various C99 language
feeatures ought to be.
Thanks.
On 2022-03-31 at 20:12:09, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
quoted
A separate weather balloon for C99 as a whole was raised separately
in 7bc341e2 (git-compat-util: add a test balloon for C99 support,
2021-12-01). Hopefully, as we find out that all C99 features are OK
on all platforms we care about, we can stop probing the features we
want one-by-one like this
Unfortunately this really isn't the case at all, the norm is for
compilers to advertise that they support verison X of the standard via
these macros when they consider the support "good enough", but while
there's still a long list of unimplemented features before they're at
100% support (and most never fully get to 100%).
We also need to worry about the stdlib implementation, and not just the
compiler, see e.g. the %zu format and MinGW in the exchange at
https://lore.kernel.org/git/220318.86bky3cr8j.gmgdl@evledraar.gmail.com/
and
https://lore.kernel.org/git/a67e0fd8-4a14-16c9-9b57-3430440ef93c@gmail.com/;
But I think we're thoroughly past needing to worry about basic language
features in C99 such as these inline variable declarations.
Well, that makes it sound like the C99 weather balloon was almost
useless, doesn't it?
I think if we were talking about C17, maybe. But as I said in my commit
message, C99 is over two decades old and required for the POSIX version
which came out in 2001. I'm aware of only two platforms we care about
that don't support that POSIX version, which are NonStop and Windows.
I think the likelihood of this being a problem is very low. And I think
we can justifiably expect that major syntactic functionality is
available when the define is set accordingly. I am also willing to
simply tell people that a compiler that includes the define and doesn't
include the requisite features is buggy and ask them to use a modern
version of GCC or clang. But, ultimately, given we're talking about
C99, this is extremely unlikely to ever be a problem in 2022.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
On Thu, Mar 31 2022, brian m. carlson wrote:
[[PGP Signed Part:Undecided]]
On 2022-03-31 at 20:12:09, Junio C Hamano wrote:
quoted
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
quoted
A separate weather balloon for C99 as a whole was raised separately
in 7bc341e2 (git-compat-util: add a test balloon for C99 support,
2021-12-01). Hopefully, as we find out that all C99 features are OK
on all platforms we care about, we can stop probing the features we
want one-by-one like this
Unfortunately this really isn't the case at all, the norm is for
compilers to advertise that they support verison X of the standard via
these macros when they consider the support "good enough", but while
there's still a long list of unimplemented features before they're at
100% support (and most never fully get to 100%).
We also need to worry about the stdlib implementation, and not just the
compiler, see e.g. the %zu format and MinGW in the exchange at
https://lore.kernel.org/git/220318.86bky3cr8j.gmgdl@evledraar.gmail.com/
and
https://lore.kernel.org/git/a67e0fd8-4a14-16c9-9b57-3430440ef93c@gmail.com/;
But I think we're thoroughly past needing to worry about basic language
features in C99 such as these inline variable declarations.
Well, that makes it sound like the C99 weather balloon was almost
useless, doesn't it?
I think if we were talking about C17, maybe. But as I said in my commit
message, C99 is over two decades old and required for the POSIX version
which came out in 2001. I'm aware of only two platforms we care about
that don't support that POSIX version, which are NonStop and Windows.
What I'm referring to upthread is that if you look at
e.g. https://gcc.gnu.org/c99status.html and compare it to
https://gcc.gnu.org/releases.html you can see that GCC (which is usually
really early with these things) was still implementing major C99
features like "inline" (it had its own syntax, but not the C99 one) in
2008.
So, part of this is just unintentional commentary on how old I'm getting
:), I hadn't looked before sending the upthread, but I remembered this
being a bit closer to $(date).
In any case, I think that shows a typical pattern where compiler
implementations are still catching up with standards at least 5-10 years
after they're released.
If you then look at C11 at https://gcc.gnu.org/wiki/C11Status you can
see that _Generic took until April 2014 with GCC 4.9, and
e.g. https://access.redhat.com/solutions/19458 notes that RHEL 7 (still
in wide use) was released with GCC 4.8, and RHEL 6 with 4.4.
(I wouldn't be surprised if RedHat had sneakily backported some
features, so don't take that as gospel about what is and isn't supported
on that platform).
I think the likelihood of this being a problem is very low. And I think
we can justifiably expect that major syntactic functionality is
available when the define is set accordingly.
Indeed, I only meant to suggest that we might still need to be careful
with some of the more exotic features, and do some research similar to
the above.
E.g. I wouldn't be at all surprised if some of the long-tail compilers
we support (suncc, xlc, msvc) had implemented some parts of C99 much
later.
I am also willing to simply tell people that a compiler that includes
the define and doesn't include the requisite features is buggy and ask
them to use a modern version of GCC or clang.
So we can drop MinGW & I can use %zu? Yay! :)
More seriously, I don't think we should have such a blanket
policy.
Sure, we might decide that's worth it, but when we run into such issues
I think it's good to just weigh the trade-offs for particular
feature. See "We live in the real world" in
Documentation/CodingGuidelines for some nice wisdom.
E.g. (and I didn't recall this when I wrote most of the above) I've got
33665d98e6b (reftable: make assignments portable to AIX xlc v12.01,
2022-03-28) in "next" right now which undoes some small use of C99
syntax because a (buggy) version of xlc isn't too happy about an
edge-case of valid C99 initializer syntax.
Now, we could just say we won't support that compiler, but as argued in
that commit message it's relatively easy to accommodate it, so being a
bit lenient with what subset of the standard we insist on seems prudent.
But, ultimately, given we're talking about
C99, this is extremely unlikely to ever be a problem in 2022.
Per the above it was a (small) problem on 2022-03-28 :)