_PFLINK is supposed to automatically pull in required functions for
specific conversion specifiers. However, it fails to do so for the F,
G and E conversion specifiers.
This means that, for example, the following program:
#include <stdio.h>
int main()
{
printf("%F %G %E\n", .0, .0, .0);
}
fails to run correctly, printing "? ? ?" instead of
"0.000000 0 0.000000E+00".
This patch fixes this.
The C standard states:
> Unless explicitly stated otherwise, the functions described in this
> subclause order two wide characters the same way as two integers of
> the underlying integer type designated by wchar_t.
>
> [...]
>
> The wcscmp function returns an integer greater than, equal to, or
> less than zero, accordingly as the wide string pointed to by s1 is
> greater than, equal to, or less than the wide string pointed to by
> s2.
>
> [...]
>
> The wcsncmp function returns an integer greater than, equal to, or
> less than zero, accordingly as the possibly null-terminated array
> pointed to by s1 is greater than, equal to, or less than the
> possibly null-terminated array pointed to by s2.
- C Standard, 7.31.4.4. Wide string comparison functions
Cosmopolitan fails to obey this in cases where the difference between
two wide characters is larger than WCHAR_MAX.
This means that, for example, the following program:
#include <stdio.h>
#include <wchar.h>
#include <limits.h>
int main()
{
wchar_t str1[] = { WCHAR_MIN, L'\0' };
wchar_t str2[] = { WCHAR_MAX, L'\0' };
printf("%d\n", wcscmp(str1, str2));
printf("%d\n", wcsncmp(str1, str2, 2));
}
will print `1` twice, instead of the negative numbers mandated by the
standard (as WCHAR_MIN is less than WCHAR_MAX)
This patch fixes this, along with the associated Github issue,
https://github.com/jart/cosmopolitan/issues/783
The C standard states that, within the context of a printf-family
function, when specifying the precision of a conversion specification:
> A negative precision argument is taken as if the precision were
> omitted.
- Quoth the C Standard, 7.23.6.1. The fprintf function
Cosmopolitan instead treated negative precision arguments as
though they had a value of 0, which was non-conforming. This
change fixes that. Another issue we found relates to:
> For o conversion, it increases the precision, if and only if
> necessary, to force the first digit of the result to be a zero (if
> the value and precision are both 0, a single 0 is printed).
- Quoth the C standard, 7.23.6.1.6. The fprintf function
When printing numbers in their alternative form, with a precision and
with a conversion specifier of o (octal), Cosmopolitan wasn't following
the standard in two ways:
1. When printing a value with a precision that results in 0-padding,
cosmopolitan would still add an extra 0 even though this should be
done "if and only if necessary"
2. When printing a value of 0 with a precision of 0, nothing is
printed, even though the standard specifically states that a single
0 is printed in this case
This change fixes those issues too. Furthermore, regression tests have
been introduced to ensure Cosmopolitan continues to be conformant
going forward.
Fixes#774Fixes#782Fixes#789
Cosmopolitan now conforms to the C Standard 7.8.1 specification
of the PRI and SCN macros, because this change fixes a bug where
the FAST16 ones were incorrectly using the %hd specifier.
The standard states that, when the # flag is used:
> The result is converted to an "alternative form". [...] For x (or X)
conversion, a nonzero result has 0x (or 0X) prefixed to it.
- C standard, 7.23.6.1. The fprintf function
cosmopolitan fails to use the correct alternative form (0X) when the X
conversion specifier is used, instead using 0x, which is not
capitalized.
This patch fixes this, along with the several tests that test for the
wrong behavior.
We were checking for anonymous mappings earlier on Windows by seeing if
the file descriptor argument to mmap() was supplied as -1. This was not
correct. The proper thing to do is check `flags & MAP_ANONYMOUS`.
The C standard states, for conversions using the d, i, b, B, o, u, x or X conversion specifiers:
> The precision specifies the minimum number of digits to appear; if
> the value being converted can be represented in fewer digits, it is
> expanded with leading zeros.
- C standard, 7.23.6.1. The fprintf function
However, cosmopolitan currently suppresses the addition of leading
zeros when the minus flag is set. This is not reflected by anything
within the C standard, meaning that behavior is incorrect.
This patch fixes this.
* Implement S conversion specifier for printf-related functions
POSIX specifies that a conversion specifier of S must be interpreted
the same way as %ls. This patch implements this.
* clang-format
---------
Co-authored-by: Gavin Hayes <gavin@computoid.com>
Python triggered the undefined behavior previously since it appears to
be posting to a semaphore owned by a different process that wasn't set
to process shared mode. The performance loss to process shared futexes
is so low and semaphores are generally used for this purpose, so it'll
be much simpler to simply not impose undefined behavior here.
This fixes a bug where the caller's timeval will be clobbered on Linux.
The Kernel ABI *always* modifies the timeout argument but POSIX says it
should be a const parameter. The wrapper now handles the difference and
sys_select() may be used if obtaining the remainder on Linux is needed.
The system call wrapper was wrongfully reinterpreting kernel data. The
examples/sysinfo.c program is now updated to show how to correctly use
what's returned.
libc/sock/if.h is removed because:
- it contained only IFNAMSIZ, which was also defined in
libc/sock/struct/ifreq.h
- it was not included in any file EXCEPT libc/isystem/net/if.h, which
also included the libc/sock/struct/ifreq.h
hence we remove this file, and move the IFNAMSIZ definition to
libc/sock/struct/ifreq.h which is included in isystem.
IFNAMSIZ is defined in:
- libc/sock/if.h
- libc/sock/struct/ifreq.h
we add a check in the latter to avoid a complaint when using the
amalgamated header.
