Targeted C standard #105

New Issue

2024-05-26T11:54:23-06:00

trinity commented

2024-05-26 11:54:23 -06:00

Currently all C programs in the main branch and open PRs target C89 because I wrote them and I try to maintain compatibility with as many C compilers as possible - C89 was the first standard C (standardized by both ANSI and ISO) and is a subset of following standards (with the exception of certain features, e.g. trigraphs, that aren't used in Bonsai.

There are very few C99 features I see as necessary. One very common addition in C99 is loop-scoped variable declarations in for statements, but this can be approximated by the structure {int i; for(...) ; } and has never proven to be necessary in Bonsai code. However a somewhat minor addition that I think is necessary is <stdint.h> which provides types of known size such as uint32_t (for a 32-bit unsigned integer) or int8_t (for an 8-bit signed integer). We could live without this header file by, for example, using macros to typedef a semantic type name to either uint32_t or a type that is at least big enough for the data being kept (unsigned long int may work for an unsigned 32-bit integer but I haven't consulted the standards), but I think it would be better to just flat-out use <stdint.h> types and break compatibility with the compilers that don't support it (though I don't know which wouldn't, there are plenty of FOSS C99 compilers including GCC and Clang, and this header is probably supported by TCC).

I would like the Bonsai coreutils' C code to target the most recent POSIX API, as it already has, and a subset of the C99 language that includes all of the features already included in C89, and <stdint.h>, and does not include features of C89 that aren't part of subsequent standard editions, such as trigraphs.

Currently all C programs in the main branch and open PRs target C89 because I wrote them and I try to maintain compatibility with as many C compilers as possible - C89 was the first standard C (standardized by both ANSI and ISO) and is a subset of following standards (with the exception of certain features, e.g. trigraphs, that aren't used in Bonsai. There are very few C99 features I see as necessary. One very common addition in C99 is loop-scoped variable declarations in `for` statements, but this can be approximated by the structure `{int i; for(...) ; }` and has never proven to be necessary in Bonsai code. However a somewhat minor addition that I think *is* necessary is [`<stdint.h>`](https://en.wikibooks.org/wiki/C_Programming/stdint.h) which provides types of known size such as `uint32_t` (for a 32-bit unsigned integer) or `int8_t` (for an 8-bit signed integer). We could live without this header file by, for example, using macros to typedef a semantic type name to either `uint32_t` or a type that is at least big enough for the data being kept (`unsigned long int` *may* work for an unsigned 32-bit integer but I haven't consulted the standards), but I think it would be better to just flat-out use `<stdint.h>` types and break compatibility with the compilers that don't support it (though I don't know which wouldn't, there are plenty of FOSS C99 compilers including GCC and Clang, and this header is probably supported by TCC). I would like the Bonsai coreutils' C code to target the most recent POSIX API, as it already has, and a subset of the C99 language that includes all of the features already included in C89, and `<stdint.h>`, and does not include features of C89 that aren't part of subsequent standard editions, such as trigraphs.

trinity added the enhancement question labels 2024-05-26 11:54:23 -06:00

trinity commented

2024-05-28 06:01:26 -06:00

On second thought, I don't think having to consult the spec for minimums/maximums supported by variables is too bad. For uint32_t specifically, the following code is fine:

#if __STDC_VERSION__ >= 199901L /* C99 */
#	include <stdint.h>
typedef uint32_t rune_t;
#else
/* Must hold at least 32b; see the C89 draft 2.2.4.2
 * <http://jfxpt.com/library/c89-draft.html#2.2.4.2> */
typedef unsigned long int rune_t;
#endif

And other byte lengths can be improvised with fundamental C types. I'd really like to sustain C89 to make porting these coreutils (to other systems or C libraries) as easy as possible.

On second thought, I don't think having to consult the spec for minimums/maximums supported by variables is too bad. For `uint32_t` specifically, the following code is fine: ```c #if __STDC_VERSION__ >= 199901L /* C99 */ # include <stdint.h> typedef uint32_t rune_t; #else /* Must hold at least 32b; see the C89 draft 2.2.4.2 * <http://jfxpt.com/library/c89-draft.html#2.2.4.2> */ typedef unsigned long int rune_t; #endif ``` And other byte lengths can be improvised with fundamental C types. I'd really like to sustain C89 to make porting these coreutils (to other systems or C libraries) as easy as possible.

trinity closed this issue

2024-05-28 06:01:26 -06:00

trinity added the wontfix label 2024-05-28 06:01:47 -06:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bonsai/harakit#105