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: Kevin R. Bulgrien via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 21 Sep 2022 13:46:16 -0500 (CDT)
----- Original Message -----
From: "Daniel Stenberg via curl-library" <curl-library_at_lists.haxx.se>
To: "libcurl hacking" <curl-library_at_lists.haxx.se>
Cc: "Daniel Stenberg" <daniel_at_haxx.se>
Sent: Tuesday, September 20, 2022 4:24:37 AM
Subject: C99
Hello,
New mail thread to make this topic more visible. The idea of switching to C99
as the base level for curl code when we go version 8 (March 2023) is
attractive to me. I figure compilers have had some time to get compliant and
find widespread use by now!
I added a PR just now to (primarly as a test) enforce C89 on the code when gcc
is used, and it shows that we are already a bit sloppy in C89 compliance in
several areas of our code base: https://github.com/curl/curl/pull/9542
But what does "going C99" mean for us? The C99 standard brought a whole
busload of different new features to the language compared to C89, and some of
them are:
— `//` comments
— `__func__` predefined identifer
— boolean type in `<stdbool.h>`
— designated struct initializers
— empty macro arguments
— extended integer types in `<inttypes.h>` and `<stdint.h>`
— fexible array members (zero size arrays)
— inline functions
— integer constant type rules
— mixed declarations and code
— the `long long` type and library functions
— the `snprintf()` family of functions
— trailing comma allowed in enum declaration
— vararg macros
— variable-length arrays
I am not entirely convinced we want to go all-in and totally crazy on all
these fronts immediately, and I think having an idea what we want in terms of
code style is a good idea to have thought about before the flood gates open.
At the same time, if we accept C99 it will be hard to enforce restrictions
with compilers and checksrc certainly will not stop most of the things in that
list (the //-comments perhaps being the single exception).
Thoughts?
----- End Original Message -----
As it is unclear (to me) what impact this might have, these two cents
may be less than relevant, but today for the first time, a build of
curl 7.85.0 with libssh2 1.10.1_DEV (with six of my own patches to the
upstream release) and openssl 3.0.3 (with five of my own patches to
the upstream release) on SCO Openserver 5.0.7 was done by me using
gcc 2.95.3.
Whereas until today I didn't manage to get the likes of sftp/scp/tls1.3
working in curl on this platform, now tests show it is possible to see
some of these working. Granted that one should prefer not to be using
such a dinosaur, but it is not always in one's capacity to effect
changes of this nature in some organizations when proprietary,
legacy software depends on the platform.
It would be a shame to break an ability to build on this legacy platform
though it isn't clear that this might be a result of the C99 changes.
https://gcc.gnu.org/c99status.html shows 2.95.3 has some capabilities
described by C99 but also states:
"C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used; -fextended-identifiers also needed to enable extended identifiers before GCC 5), modulo bugs and floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G)."
Some software that demand C99 fail to build under gcc 2.95.3. I have
observed this with xz (https://tukaani.org/xz/).
All that said, I have successfully built gcc 3.4.6, and, as of a few
weeks ago, finally attempted and succeeded at building gcc 4.2.4, so
some further use of C99 would be possible without necessarily breaking
an ability to build on this platform. (Incidentally, XINUOS has recently
published XDEV (an Extended DEVelopment environment) for Openserver
5.0.7 Definitive, and provides gcc 4.2.4 as part of that suite.)
The build procedure I developed and use makes it possible to package
software in a native CDMT/VOL format which is able to install and
uninstall binary packages via the 'custom' package manager on
Openserver 5.0.7.
Getting to this point has been a long haul for one of my experience level,
and I'd say this is out of reach of a lot of people who happen to support
this old platform (unless they opted for XINUOUS XDEV or a third-party
upgraded gcc and friends). It was necessary to build updates to a number
of gnu tools, build a newer perl, etc. Until I manage to leverage a
transition to Linux here, I'll continue to depend on curl being buildable
on this platform... and I am very grateful that the project has been so
focused on preserving an ability to build on legacy systems.
Date: Wed, 21 Sep 2022 13:46:16 -0500 (CDT)
----- Original Message -----
From: "Daniel Stenberg via curl-library" <curl-library_at_lists.haxx.se>
To: "libcurl hacking" <curl-library_at_lists.haxx.se>
Cc: "Daniel Stenberg" <daniel_at_haxx.se>
Sent: Tuesday, September 20, 2022 4:24:37 AM
Subject: C99
Hello,
New mail thread to make this topic more visible. The idea of switching to C99
as the base level for curl code when we go version 8 (March 2023) is
attractive to me. I figure compilers have had some time to get compliant and
find widespread use by now!
I added a PR just now to (primarly as a test) enforce C89 on the code when gcc
is used, and it shows that we are already a bit sloppy in C89 compliance in
several areas of our code base: https://github.com/curl/curl/pull/9542
But what does "going C99" mean for us? The C99 standard brought a whole
busload of different new features to the language compared to C89, and some of
them are:
— `//` comments
— `__func__` predefined identifer
— boolean type in `<stdbool.h>`
— designated struct initializers
— empty macro arguments
— extended integer types in `<inttypes.h>` and `<stdint.h>`
— fexible array members (zero size arrays)
— inline functions
— integer constant type rules
— mixed declarations and code
— the `long long` type and library functions
— the `snprintf()` family of functions
— trailing comma allowed in enum declaration
— vararg macros
— variable-length arrays
I am not entirely convinced we want to go all-in and totally crazy on all
these fronts immediately, and I think having an idea what we want in terms of
code style is a good idea to have thought about before the flood gates open.
At the same time, if we accept C99 it will be hard to enforce restrictions
with compilers and checksrc certainly will not stop most of the things in that
list (the //-comments perhaps being the single exception).
Thoughts?
----- End Original Message -----
As it is unclear (to me) what impact this might have, these two cents
may be less than relevant, but today for the first time, a build of
curl 7.85.0 with libssh2 1.10.1_DEV (with six of my own patches to the
upstream release) and openssl 3.0.3 (with five of my own patches to
the upstream release) on SCO Openserver 5.0.7 was done by me using
gcc 2.95.3.
Whereas until today I didn't manage to get the likes of sftp/scp/tls1.3
working in curl on this platform, now tests show it is possible to see
some of these working. Granted that one should prefer not to be using
such a dinosaur, but it is not always in one's capacity to effect
changes of this nature in some organizations when proprietary,
legacy software depends on the platform.
It would be a shame to break an ability to build on this legacy platform
though it isn't clear that this might be a result of the C99 changes.
https://gcc.gnu.org/c99status.html shows 2.95.3 has some capabilities
described by C99 but also states:
"C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used; -fextended-identifiers also needed to enable extended identifiers before GCC 5), modulo bugs and floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G)."
Some software that demand C99 fail to build under gcc 2.95.3. I have
observed this with xz (https://tukaani.org/xz/).
All that said, I have successfully built gcc 3.4.6, and, as of a few
weeks ago, finally attempted and succeeded at building gcc 4.2.4, so
some further use of C99 would be possible without necessarily breaking
an ability to build on this platform. (Incidentally, XINUOS has recently
published XDEV (an Extended DEVelopment environment) for Openserver
5.0.7 Definitive, and provides gcc 4.2.4 as part of that suite.)
The build procedure I developed and use makes it possible to package
software in a native CDMT/VOL format which is able to install and
uninstall binary packages via the 'custom' package manager on
Openserver 5.0.7.
Getting to this point has been a long haul for one of my experience level,
and I'd say this is out of reach of a lot of people who happen to support
this old platform (unless they opted for XINUOUS XDEV or a third-party
upgraded gcc and friends). It was necessary to build updates to a number
of gnu tools, build a newer perl, etc. Until I manage to leverage a
transition to Linux here, I'll continue to depend on curl being buildable
on this platform... and I am very grateful that the project has been so
focused on preserving an ability to build on legacy systems.
-- Kevin R. Bulgrien -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-21