We now require C90, but the C99 standard is 25 years old. It's time. As discussed in #772 (reply in thread), moving to C99 can fix undefined behaviour (UB) that the ast and ksh code base is currently suffering from:
- Lots of uses of the struct hack in libast and ksh, for example, the final
dolval/argval members of struct dolnod and struct argnod which are central to command arguments processing in ksh. It works in practice because C90 had no alternative and compiler implementers just made it work and allowed out-of-bounds array access regardless of what the standard said. But C99 does have a good construct for exactly that use case (flexible array members), so we should use it. There is no guarantee the struct hack will still work in practice 25 years from now. The change should be made very carefully as flexible array members have a size of zero, so the often-used sizeof of these structs will change.
- Undefined behaviour in many places with regards to float values and their typecasts to/from integer values, e.g., this typecast which has UB if the float value is infinite or is not a number (NaN), a scenario which can easily occur in practice. To fix issues like these we need
fpclassify(3) and/or isnan(3), isinf(3), etc., which were all introduced in C99. The libast code does feature tests for these now, so we could implement the fixes conditionally, but it's 2024 and it's better just to require them at this point.
- More to be found?
We now require C90, but the C99 standard is 25 years old. It's time. As discussed in #772 (reply in thread), moving to C99 can fix undefined behaviour (UB) that the ast and ksh code base is currently suffering from:
dolval/argvalmembers of struct dolnod and struct argnod which are central to command arguments processing in ksh. It works in practice because C90 had no alternative and compiler implementers just made it work and allowed out-of-bounds array access regardless of what the standard said. But C99 does have a good construct for exactly that use case (flexible array members), so we should use it. There is no guarantee the struct hack will still work in practice 25 years from now. The change should be made very carefully as flexible array members have a size of zero, so the often-usedsizeofof these structs will change.fpclassify(3) and/orisnan(3),isinf(3), etc., which were all introduced in C99. The libast code does feature tests for these now, so we could implement the fixes conditionally, but it's 2024 and it's better just to require them at this point.