On Sat, May 17, 2025 at 10:08:45PM -0500, Eric Blake via M4-patches wrote: > Here's all my pending eval patches after a bit more polish. In > particular, I'm liking the idea in patch 4 of having eval default to > 32-bit mode when eval64 is also easy to access, but defaulting to the > size of 'signed long' as a platform-dependency in 'm4 -G', plus a new > command-line option '--eval=32' or '--eval=64' to force the size. > > But I'm still open to any comments on whether this is the best > approach for gaining a bit more POSIX compability (remember, in one > place, POSIX says eval must use at least 32-bit signed math; in > another, it says math operators of all the standard utilities must > default to 'signed long').
Interestingly, if eval() is patched to support 64-bits, but format() is not, then on 32-bit platforms, there is no easy way to format the output of 64-bit eval (sure, you can right- or left-justify strings, but filling padding with space or placing space between the sign and the rest of the number requires integer not string handling). In the opposite direction, format has long been able to support %ld on 64-bit platforms, which parses a decimal (only!) number; but it would be nice to be able to format 64-bit hex constants without having to convert them to decimal first (especially if eval can't do the conversion). So I need to patch format() as well as eval - but format is not POSIX, so I'm less constrained there. I'm thinking of teaching format() to support %lld and friends, and also the ability to parse "0b...", "0o...", "0x...", and "0rNN:...", while keeping leading 0 as decimal for back-compat but issuing a warning when that happens (other than for bare "0", which, although it is technically a C octal constant, is not confusing like other leading 0 values on whether it is decimal or octal). The 0o would be new (gnulib's strtoll doesn't support it yet, but [1] implies that C will get there soon enough), and warning on a leading 0 while still parsing it as decimal (rather than forcing an octal parse, the way eval() must behave) will involve some hand-holding rather than straight strtoll() calls. [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3353.htm I'm also debating about whether other m4 builtins can accept non-decimal values. For example, POSIX says incr() is undefined if given a non-numeric argument (does using '-' to increment a negative number count as non-numeric?), but being strictly more permissive than before isn't going to break back-compat. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org _______________________________________________ M4-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/m4-patches
