"prom" root device variable; junk past the trailing NUL would cause
the way we parse the string to fail. Also parse rootdev= and root=
the same way ("be liberal in what you accept" approach).
_LITTLE_ENDIAN or _BIG_ENDIAN is defined) with standard check
"#if BYTE_ORDER == BIG_ENDIAN" like we do it elseware.
Should fix PR 56191 (ZFS tests fail on sparc64)
The output was:
UBSan: Undefined Behavior in ../../../../arch/arm/rockchip/
rk_cru_composite.c:86:21, unsigned integer overflow: 0 divrem 0 cannot be
represented in type 'unsigned int'
The output was:
UBSan: Undefined Behavior in ../../../../arch/arm/rockchip/rk3399_cru.c:
284:13, signed integer overflow: 594000000 - -2086967296 cannot be
represented in type 'int'
In ixgbe, TX/RX descriptor rings are configured in 16-byte units.
If BUS_DMA_COHERENT is not specified, cpu cache (writeback/invalidate)
operations by bus_dmamap_sync() in aarch64 (arm/arm32/bus_dma.c) are done per
cache line size (usually 64 bytes). As a result, adjacent descriptors conflict
with the DMA operation, resulting in unstable operation.
To avoid this, descriptors area should be mapped as non-cache with BUS_DMA_COHERENT.
thanks to msaitoh@ for his help in debugging.
of the form '+1 (two (or more) characters after the quote) will now generate
an error message, and cause printf(1) to exit(1) when it is done.
Adapt the test cases which use that data form to handle that.
1. exit(1) with an error message on stderr if an I/O error occurs.
1a. To work properly when built into /bin/sh sprinkle clearerr() at
appropriate places.
2. Verify that when a 'X data value is used with one of the numeric
conversions, that nothing follows the 'X'. It used to be unclear
in the standard whether this was required or not, it is clear that
with numeric conversions the entire data value must be used, or an
error must result. But with string conversions, that isn't the case
and unused parts are simply ignored. This one is a numeric conversion
with a string value, so which applies? The standard used to contain
an example of '+3 being converted, producing the same as '+ ignoring
the '3' with no mention of any error, so that's the approach we adopted,
The forthcoming version now explicitly states that an error would also
be generated from that case, as the '3' was not used by the numeric
conversion.
2a. We support those conversions with floating as well as integer conversions,
as the standard used to suggest that was required (but it makes no sense,
the values are always integers, printing them in a floating format is
dumb). The standard has been revised to make it clear that only the
integer numeric conversions %d %u %x (etc) are supposed to handle the 'X
form of data value. We still allow it with the floating formats as an
extension, for backward compat, just in case someone (other than the ATF
tests) is using it. It might go away.
2b. These formats are sypposed to convert 'X where 'X' is a character
(perhaps multibyte encoded) in the current LC_CTYPE locale category.
We don't handle that, only 1 byte characters are handled currently.
However the framework is now there to allow code to (one hopes, easily)
be added to handle multi-byte locales. (Note that for the purposes of
#2 above, 'X' must be a single character, not a single byte.)
to why this didn't cause any failures, but I won't go into it here.
This was detected by the about to be committed printf changes.
While here also correct a couple of minor comment layout issues.
Clang is stricter than GCC when it comes to nonliteral format strings.
sys/net/lagg/if_lagg.c:2372:12: error:
format string is not a string literal [-Werror,-Wformat-nonliteral]
Oguz <oguzismailuysal@gmail.com>
If echo detects an I/O error, it does exit(1) (that's fine) but then
the next echo also does exit(1) even without any errors of its own,
and every following echo writing to stdout does the same thing.
eg:
echo foo >&- ; echo $?; echo $?; ( echo $( echo $?; echo $?) ; echo $? )
1
1
1 1
1
The first echo writes nothing (stdout is closed) but does exit(1).
The second echo writes "1" (correct, the exit status of the previous
echo) and should exit(0) - but doesn't. This pattern continues...
While here, conform to the POSIX requirement on echo (and many other
standard utilities, but definitely not all) that when the utility
does exit(>0) a message must be written to stderr (and vice versa
in many cases). Our echo (as shown above) did the exit(1) part
when it detected the I/O error, but no message is sent to stderr.
Fix that while we're here.
Similar changes are required for /bin/echo (coming soon), and
/usr/bin/printf (which is also the sh builtin printf) - except
currently that one kind of conforms, as it ignores errors writing
to stdout (as do large numbers of other utilities). For many
programs that's kind of acceptable, but where the sole purpose of
the program is to write to stdout, it really isn't. Also to be
fixed soon.
The first verifies that echo exits >0 when it encounters an I/O error on
its output (this part would have succeeded for a long time). It also
verifies the POSIX requirement that when most standard utilities (or
perhaps many rather than most) exit(>0) they must write a message to stderr.
Our sh's built in echo did not do that (nor does /bin/echo but that's not
relevant here).
The second demonstrates (on an unfixed built-in echo) a bug reported in
private e-mail by Oguz <oguzismailuysal@gmail.com> where once an instance of
the built-in echo has detected an I/O error, all later invocations of
the built-in echo, with no I/O errors of their own, also exit(1) (the error
status on stdout is not cleared, each echo sees the "I/O error occurred" and
does exit(1)).
In this second sub-test, the "2>&-" on the first echo command is simply
an artifact caused by the test harness - the "check" function verifies
that exit((>0) requires a message on stderr (and vice versa), but that
only applies to most (or many) utilities, echo is one, but sh is not.
In the second test, the exit status comes from sh - sh is permitted to
write to stderr (via the echo command it runs in this case) and still
exit(0). But the check function in the test does not understand that
subtlety. So, we simply suppress the stderr message by closing stderr
(the first of these two new sub-tests has verified that the message exists)..
mrg