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: bch via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 20 Sep 2022 09:54:44 -0700
On Tue, Sep 20, 2022 at 08:06 Emil Engler via curl-library <
curl-library_at_lists.haxx.se> 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.
-bch
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: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
Date: Tue, 20 Sep 2022 09:54:44 -0700
On Tue, Sep 20, 2022 at 08:06 Emil Engler via curl-library <
curl-library_at_lists.haxx.se> 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.
-bch
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: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-20