This stemmed from its calling strtoul internally, causing it to accept extra while space and/or + signs. The fix is to have an alternate entry point for strtoul that skips that processing.
This could happen if a scan error occurred and certain conversion specifiers containing the % character in a scanset (e.g. %4[%]) appeared as subsequent elements in the format string. The fix is to more thoroughly parse the format string when cleaning up after a scan error.
This fixes#26.
It had been doing a null pointer dereference and effectively treating memory locations starting from 0 as the continuation of the string, potentially producing inappropriate results depending on what they contained.
The issue was introduced in commit 6e9790667.
errno is now set to EINVAL in this case. (This is not required by the C standards, but is consistent with various other implementations.)
This fixes the cases in #23 related to strtol() and strtoul().
In other bases, the 'x' either ends parsing of the number string or (in base 34 and larger) is a digit.
Also, ensure only ASCII characters (with high bit clear) are accepted in all situations.
They could previously give the wrong sign on the remainder in certain cases where one or both of the arguments were negative, because they were using the wrong condition to decide whether to negate it.
This exits the programs without calling atexit functions and possibly without doing other clean-up operations. In ORCA/C, it is functionally identical to _exit().
perror() should write only a single new-line. Also, it should not write the prefix string, colon and space if the prefix string pointer is NULL or if it points to an empty string.
Previously, it just ran an Execute shell call with NULL as the command-line pointer.
The fix is to still call Execute, but with an empty string as the command line, and then check if the call gave an error. If running under plain GS/OS, this gives an error for an unknown system call, whereas both ORCA/APW and GNO shells will return with no error in this case. (Golden Gate doesn't implement the Execute shell call, so it also gives an error and will report no command processor available.)
This fixes issue #25.
These all behave identically to 'f'. Note that none of these accept the hexadecimal floating-point representation as input, which they should under C99.
'F' is currently treated identically to 'f'. This should be a correct implementation for 'F' under C99. (It's not quite correct for 'f', which should print "inf" or "nan" in lower case according to C99.)
'A' and 'a' are not correctly formatted (they are currently treated identically to 'E' and 'e', rather than using the hexadecimal floating-point representation specified by C99), but at least they print the number in some form and consume the correct number of bytes so that the stack isn't corrupted and subsequent conversion specifications print the right values.
The floating-point formats are also moved to the top of the list of conversion specifiers to check, which means they are checked last. This should marginally speed up the integer cases.
'z' corresponds to size_t, 't' to ptrdiff_t, and 'j' to intmax_t. In ORCA/C, these are all 32-bit types, so these size modifiers are equivalent to 'l'. (Note that C99/C11 require intmax_t to be at least 64-bit, but that is not currently the case in ORCA/C since there is no 64-bit integer type.)
The reverted changes relate mainly to adding a second character position in the putback buffer, but the library with those changes crashes on basic stdio operations like printing a string.
For now, this patch reverts stdio to a working, tested version. If the reverted changes are valuable, they can be fixed and then reintroduced later.
