Targeted C standard #105
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 asuint32_t
(for a 32-bit unsigned integer) orint8_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 eitheruint32_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.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: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.