Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: C99
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 21 Sep 2022 12:56:42 -0700
On Wed, Sep 21, 2022 at 11:50:50AM -0700, Ben Greear via curl-library wrote:
> My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
> systems with old compilers...
This certainly makes life easier for people who are forced to use
ancient systems, but it doesn't come for free. curl developers are then
stuck in a time warp from 33 years ago, a time when 79% of adults alive
today weren't even born. None of the improvements in the language made
in the subsequent one-third century are available to us to improve the
development experience.
Kevin's message highlights another issue; even if curl can be built on a
21-year-old compiler, lots of other packages can't. And in the world of
the Internet of 2022, you can't rely on older packages because of
security concerns. So, what's the point of begin able to compile the
latest curl to get its security fixes when you're forced to use an
outdated TLS library riddled with security issues, or run on a kernel
that has been broken a dozen times over, or use a libc full of security
holes?
Moving to C18 (or C23) right now isn't on the table, since it does take
a while for toolchains to get that support. But, at some point we're
going to have to say that if people want the benefits of the latest
curl, they're going to have to use a compiler made in the same
millennium. One could go so far as to argue that keeping C89
compatibility is irresponsibly encouraging users to stick with outdated
dependencies with security issues and is therefore harmful to the
Internet as a whole.
I could actually go back and rewrite this e-mail to replace C89 with C99
and make pretty close to the same arguments. C99 will be just a few
months shy of a quarter century old by the time this proposal would kick
in next year. Maybe the proposal should really be to switch directly to
C11 (instead of C99), since it will already be 12 years old by the time
of curl 8.0. That's probably too aggressive, though, since there are
companies around today back-porting security fixes into software nearly
that old, so it's harder to make the irresponsibility argument for that
one.
Dan
Date: Wed, 21 Sep 2022 12:56:42 -0700
On Wed, Sep 21, 2022 at 11:50:50AM -0700, Ben Greear via curl-library wrote:
> My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
> systems with old compilers...
This certainly makes life easier for people who are forced to use
ancient systems, but it doesn't come for free. curl developers are then
stuck in a time warp from 33 years ago, a time when 79% of adults alive
today weren't even born. None of the improvements in the language made
in the subsequent one-third century are available to us to improve the
development experience.
Kevin's message highlights another issue; even if curl can be built on a
21-year-old compiler, lots of other packages can't. And in the world of
the Internet of 2022, you can't rely on older packages because of
security concerns. So, what's the point of begin able to compile the
latest curl to get its security fixes when you're forced to use an
outdated TLS library riddled with security issues, or run on a kernel
that has been broken a dozen times over, or use a libc full of security
holes?
Moving to C18 (or C23) right now isn't on the table, since it does take
a while for toolchains to get that support. But, at some point we're
going to have to say that if people want the benefits of the latest
curl, they're going to have to use a compiler made in the same
millennium. One could go so far as to argue that keeping C89
compatibility is irresponsibly encouraging users to stick with outdated
dependencies with security issues and is therefore harmful to the
Internet as a whole.
I could actually go back and rewrite this e-mail to replace C89 with C99
and make pretty close to the same arguments. C99 will be just a few
months shy of a quarter century old by the time this proposal would kick
in next year. Maybe the proposal should really be to switch directly to
C11 (instead of C99), since it will already be 12 years old by the time
of curl 8.0. That's probably too aggressive, though, since there are
companies around today back-porting security fixes into software nearly
that old, so it's harder to make the irresponsibility argument for that
one.
Dan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-21