RFC: Switching from C90 to C99

[creachadair]

When I originally wrote IMath in 2001–2002, I intentionally aimed for compatibility with ISO/IEC 9899:1990. At the time, consensus seemed to be that C90 was a better bet for compatibility—C99 was available, but neither widely nor completely supported.

As of 2018 feature support for C99 seems to be a better bet, and in fact I've already (carelessly, but I think without harm) allowed some features to creep into the code (e.g., stdint.h). Given that the Makefile already includes -std=c99 for GCC and Clang, the next reasonable question is whether we should embrace C99 more fully in IMath?

The C99 Wikipedia article includes a survey of C99 support, which suggests that most compilers have "full" or "partial" support for C99. According to that article, the missing features are mainly around floating-point and complex number support, UCNs, type-generic math, and some lexical issues. None of these is really important for IMath. As usual, Wikipedia data should be taken with a grain of salt, but this seems encouraging.

I would like to use C99 for to make these changes:

1. [x] Get rid of some or all of the macros, using inline functions.
2. [x] Improve readability by moving variable declarations closer to their use. In particular, I would like to move loop indices inside the loop signature.
3. [x] Use variable-length arrays in temporary setup/cleanup.
4. [x] Use the new bool type to improve legibility and type-safety where appropriate.

None of these are essential to functionality, but I think would make the code easier to read and debug.

If anyone who uses IMath has comments on this proposal, I would welcome your input.

[nmisch]

PostgreSQL is conservative about build requirements, and it started requiring C99 in August: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d9dd406fe281d22d5238d3c26a7182543c711e74

This would pose no trouble for PostgreSQL's use of IMath, and it does not seem rash in general.

On Thu, Dec 06, 2018 at 06:24:25PM +0000, M. J. Fromberger wrote:

When I originally wrote IMath in 2001–2002, I intentionally aimed for compatibility with ISO/IEC 9899:1990. At the time, consensus seemed to be that C90 was a better bet for compatibility—C99 was available, but neither widely nor completely supported.

As of 2018 feature support for C99 seems to be a better bet, and in fact I've already (carelessly, but I think without harm) allowed some features to creep into the code (e.g., stdint.h). Given that the Makefile already includes -std=c99 for GCC and Clang, the next reasonable question is whether we should embrace C99 more fully in IMath?

The C99 Wikipedia article includes a survey of C99 support, which suggests that most compilers have "full" or "partial" support for C99. According to that article, the missing features are mainly around floating-point and complex number support, UCNs, type-generic math, and some lexical issues. None of these is really important for IMath. As usual, Wikipedia data should be taken with a grain of salt, but this seems encouraging.

I would like to use C99 for to make these changes:

1. Get rid of some or all of the macros, using inline functions.
2. Improve readability by moving variable declarations closer to their use. In particular, I would like to move loop indices inside the loop signature.
3. Use variable-length arrays in temporary setup/cleanup.
4. Use the new bool type to improve legibility and type-safety where appropriate.

None of these are essential to functionality, but I think would make the code easier to read and debug.

If anyone who uses IMath has comments on this proposal, I would welcome your input.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/creachadair/imath/issues/29

[creachadair]

I did a very rough search probe, and found these repositories using imath.h:

https://git.postgresql.org/gitweb/?p=postgresql.git https://github.com/flockoffiles/SwiftySRP https://github.com/inducer/isl https://github.com/ip2location/ip2proxy-c

Several others use it indirectly through ISL (e.g., https://github.com/llvm-mirror/polly, https://github.com/Tiramisu-Compiler/tiramisu) and pgcrypto, but I think it likely that there aren't too many direct consumers.

[creachadair]

The macros will require some additional cleanup first, as I "cleverly" used them as lvalues in a few places.

However, once that's done I think I can make them into static inline functions in the header, though I wonder if I shouldn't leave an escape hatch for older compilers.

[creachadair]

All the function macros in the public API are now gone, the rest I think is cleanup to be done later.