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.
C99
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 20 Sep 2022 11:24:37 +0200 (CEST)
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?
Date: Tue, 20 Sep 2022 11:24:37 +0200 (CEST)
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?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-20