C99 Compliance #28

New Issue

jordan · 2024-01-13T11:36:35-05:00

jordan commented

2024-01-13 11:36:35 -05:00

ANSI C89 is not actually POSIX. POSIX specifies only C99. To maintain compliance with POSIX, ensuring broader portability of the code base, we should really upgrade to C99.

This involves:

Setting the -std=c99 compile flag.
Removing the Int.h, Int64.h, UInt64.h, and other headers and their accompanying code that can be replaced by stdint.h. Also included in this is refactoring any code that uses the custom integer types to use the stdint.h types instead.
Using stdbool.h and bool everywhere it is semantically correct, at least in the public API. Private use may still use int we come across places where it should be bool, then we should change them.
Updating printf() format specifiers to use %zu for size_t.
Determining what the style guide will be going forward.
- Do variable declarations still need to happen at the top of a scope?
- Are // comments allowed?
I am inclined to answer "no" and "yes" to these respectively. If we are targetting C99, we should be okay with using C99 features, as long as they don't hinder readability. However, there are some features that we should avoid because they are not widely supported, including VLAs, floating point pragmas, and complex numbers. I don't anticipate any of those being a problem though.

We are already using C99 functions such as snprintf(), so we aren't even strictly C89 compliant anyway.

A part of this initiative should also be to deal with #12, #16, and #20.

ANSI C89 is *not* actually POSIX. POSIX specifies only C99. To maintain compliance with POSIX, ensuring broader portability of the code base, we should really upgrade to C99. This involves: - [x] Setting the `-std=c99` compile flag. - [x] Removing the `Int.h`, `Int64.h`, `UInt64.h`, and other headers and their accompanying code that can be replaced by `stdint.h`. Also included in this is refactoring any code that uses the custom integer types to use the `stdint.h` types instead. - [x] Using `stdbool.h` and `bool` everywhere it is semantically correct, at least in the public API. Private use may still use `int` we come across places where it should be `bool`, then we should change them. - [x] Updating `printf()` format specifiers to use `%zu` for `size_t`. - [ ] Determining what the style guide will be going forward. - Do variable declarations still need to happen at the top of a scope? - Are `//` comments allowed? I am inclined to answer "no" and "yes" to these respectively. If we are targetting C99, we should be okay with using C99 features, as long as they don't hinder readability. However, there are some features that we should avoid because they are not widely supported, including VLAs, floating point pragmas, and complex numbers. I don't anticipate any of those being a problem though. We are already using C99 functions such as `snprintf()`, so we aren't even strictly C89 compliant anyway. A part of this initiative should also be to deal with #12, #16, and #20.

jordan added the

bug

enhancement

labels 2024-01-13 11:36:35 -05:00

jordan added this to the Cytoplasm v1.0.0 milestone 2024-01-13 11:37:28 -05:00

jordan pinned this 2024-01-13 11:39:26 -05:00

jordan modified the milestone from Cytoplasm v1.0.0 to Cytoplasm v0.4.1

2024-01-13 11:39:46 -05:00

jordan commented

2024-01-13 11:45:19 -05:00

Once C99 compliance is achieved, we can upgrade Telodendria as well. I imagine that there will be a number of breaking changes that will affect Telodendria.

jordan referenced a pull request that will close this issue

2024-01-13 17:13:16 -05:00

C99 Compliance #29

jordan closed this issue

2024-01-13 17:13:46 -05:00

jordan referenced this issue from a commit

2024-01-13 17:13:48 -05:00

C99 Compliance (#29)

jordan unpinned this 2024-01-13 17:14:05 -05:00

Sign in to join this conversation.