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: Ben Greear via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 21 Sep 2022 11:50:50 -0700
On 9/21/22 11:46 AM, Kevin R. Bulgrien via curl-library wrote:
> ----- 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!
Hello,
My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
systems with old compilers...
Thanks,
Ben
>
> 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
>
Date: Wed, 21 Sep 2022 11:50:50 -0700
On 9/21/22 11:46 AM, Kevin R. Bulgrien via curl-library wrote:
> ----- 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!
Hello,
My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
systems with old compilers...
Thanks,
Ben
>
> 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
>
-- Ben Greear <greearb_at_candelatech.com> Candela Technologies Inc http://www.candelatech.com -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-21