curl / Mailing Lists / curl-library / Single Mail
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

From: Ben Greear via curl-library <>
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" <>
> To: "libcurl hacking" <>
> Cc: "Daniel Stenberg" <>
> 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!


My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
systems with old compilers...


> 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:
> 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.
> 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 (
> 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 <>
Candela Technologies Inc
Received on 2022-09-21