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)..
the LK_EXCLUSIVE lock with a LK_SHARED lock.
The attributes requested were not used since Rev 1.25 of exec_elf32.c
from 1997/05/08 when mycroft GCd the va_mode check.
(Descriptions for CSV3 and CSV2 are not very good, but the blurbs in
the arm arm are an entire paragraph long each. Please fix if you have
a conciser summary!)
- dkcksum() and dkcksum_sized() move from subr_disk.c and from
libsa into libkern/dkcksum.c (which is missing _sized() version),
using the version from usr.sbin/disklabel.
- swap_disklabel() moves from subr_disk_mbr.c into libkern, now called
disklabel_swap(). (the sh3 version should be updated to use this.)
- DISKLABEL_EI becomes a first-class option with opt_disklabel.h.
- add libkern.h to libsa/disklabel.c.
this enables future work for bi-endian libsa/ufs.c (relevant for ffsv1,
ffsv2, lfsv1, and lfsv2), as well as making it possible for ports not
using subr_disk_mbr.c to include bi-endian disklabel support (which,
afaict, includes any disk on mbr-supporting platforms that do not have
an mbr as well as disklabel.)
builds successsfully on: alpha, i386, amd64, sun2, sun3, evbarm64,
evbarm64-eb, sparc, and sparc64. tested in anita on i386 and sparc,
testing in hardware on evbarm64*.
Fix typos (2nd acst should have been acdt), 0550 for ist should be 0530
(5.5 hours is not 5 hours and 50 minutes...).
Comment out the zp4 zp5 and zp6 zone names. They are supposedly supported
by the source (they're in the table) but cannot work, as the parsedate
lexer doesn't allow a "word" to start with an alpha and also contain
digits. Maybe (just maybe) that could be fixed sometime, but since these
have never worked, and no-one has ever seemed to miss them, and they're the
only words which are of that form, for now, just stop pretending they work.
Previously, declaring a bit-field of type plain 'int' resulted in this
warning:
warning: nonportable bit-field type 'int' [34]
This warning was too unspecific to be actionable, and until yesterday it
didn't even include the type. In order to allow this warning to be
understood and properly fixed, describe the actual nonportability more
precisely:
warning: bit-field of type plain 'int' has
implementation-defined signedness [344]
Seeing the message "unportable bit-field type 'int'" may sound strange
at first, but that's a strict interpretation of the wording in C99
6.7.2.1p4, which requires that the bit-field type is "'_Bool', 'unsigned
int' or 'signed int', or some other implementation-defined type".
The rationale for C99 6.7.2.1 explicitly lists plain 'int' among the
allowed types for bit-fields, regardless of any additional
implementation-defined types. This means that lint had interpreted this
paragraph wrong, and it should be fixed to allow plain int as well.
src/external/bsd/wpa/bin/hostapd/../../dist/src/common/dpp.c:5377:7:
error: format specifies type 'unsigned long' but the argument has type
'os_time_t' (aka 'long long') [-Werror,-Wformat]
See octeon_gmxreg.h 1.2 from 2020-06-18 for an example, where
RXN_RX_INBND_SPEED was cleaned up without adjusting the corresponding
code in octeon_gmx.c.
