This applies to + or - signs for 'd' or 'i' conversions, and to '0x' or '0X' prefixes for 'i' and 'x' conversions. (The new support for signs on u/o/x conversions did not have the problem.)
These cases were treated as if they successfully matched a number, but now they are correctly treated as a failure, causing no assignment to be done and causing the function to return without processing any further directives.
(Incidentally, the handling of '0x' without following digits is something that differs in modern C libraries: macOS libc, glibc, and musl are all different. Our new behavior should match that of musl, which I believe is what is correct under the C standards.)
The 'll' length modifier is now fully supported for the d, i, o, u, x, and X conversion specifiers. The 'n' conversion specifier can also store to a long long, but the value is still limited to 64k. The 'j' length modifier (for intmax_t) is also now treated as specifying a 64-bit value.
The 'b' conversion specifier is an ORCA extension to support p-strings, but lower case letters are reserved for use in future C standards, and in fact C23 is likely to use 'b' for integers in binary notation. For the time being, 'b' is still supported with its existing meaning, but it is considered deprecated. It may be removed in the future if we want to support the C23 behavior. Upper-case letters are available to use for extensions, so 'P' should remain available for our use.
For example, the output of the following should have only two leading zeros (and the rest of the field width padded with spaces):
#include <stdio.h>
int main(void) {
printf("%016.5i\n", 123);
}
If the field width is given by an argument (when * is used in the format specification) and the value given is negative, it should be treated like a positive field width with the - flag. If a negative argument is given for the precision, it should be treated as if the precision was not specified.
The following is an example of code that behaved incorrectly:
#include <stdio.h>
int main(void) {
printf("%*iXX\n", -50, 123);
}
Currently, it works as follows:
*The 'll' length modifier is recognized. 'j' (for intmax_t) is also now treated as denoting a 64-bit type.
*The 'x', 'X', and 'o' format specifiers have full support for 64-bit types.
*The 'n' format specifier can write a 64-bit integer, but only actually supports values up to 64k.
*The 'd', 'i', and 'u' format specifiers can consume a 64-bit value, but they only print it correctly if it is within the range of 32-bit long/unsigned long.
Tabs have been expanded to spaces in several files that use mainly spaces for indentation.
The files ctype.asm, stdio.asm, and string.asm consistently use tabs for indentation. The tabs in these files have been left alone, except that a few tabs between sentences in comments were changed to spaces. One space-indented line in stdio.asm was changed to use a tab.
This could happen due to a race condition, which shouldn't generally be an issue on the GS but is at least theoretically possible under GNO or Golden Gate.
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.
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.
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.