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: bch via curl-library <>
Date: Tue, 20 Sep 2022 09:54:44 -0700

On Tue, Sep 20, 2022 at 08:06 Emil Engler via curl-library <> wrote:

> On Tue, Sep 20, 2022 at 11:24:37AM +0200, Daniel Stenberg via curl-library
> wrote:
> > 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.
> While I'm not against a switch to C99, I consider most of the features
> introduced by it, to put it mildly, useless. Sure, some things of it
> are very useful and cannot be achieved by ease in C89, such as
> <stdint.h> and variadic macros, but most of the other features, such as
> <stdbool.h> and snprintf(3) can be implemeneted in C89 fairly easy and
> given the fact that curl already does that, as it has its own boolean
> type and printf(3)-functions, it's questionable if we should truly favor
> them to the cost of a slightly worser portability.
> A thing we could also do, would be to use C89 with GNU C Extensions
> (GNU89), but only make use of the GNU Extensions, which are also part of
> the C99 standard,

C89 w long long apparently, and does compile cleanly (without warnings) on
C99, according to a dev I talked to. The biggest issue (or "a big" issue)
with that standard is (lack of) file locking, but that'd be curls C89 case
as well.


as they have a big intersection with each other. With
> this approach, we can make use of certain C99 features without dropping
> portability for certain gcc versions. If I remember correctly, SQLite
> does exactly this.
> --Emil
> --
> Unsubscribe:
> Etiquette:

Received on 2022-09-20