during their allocation, which the test cannot handle properly.
2. Enable building the test without atf so that we can easily debug with
atf memory allocations interfering
3. Add memory tracing (disabled)
* Added extra testing to the addstr test to demonstrate bug described
in PR#56224 and validate case when scrolling enabled still works.
* Fixed slk test, the slk_init output changed due to corrected wrapping,
slk_restore no longer returns ERR probably due to addwchar no longer
returning ERR when an implicit scroll was attempted when scrolling
disabled. Commented out the slk_wset test, this is now returning ERR
instead of misbehaving, needs investigation.
* disable blind clearing of /tmp. The comment says this is needed for getwin/putwin
those tests need to be looked at to correct this.
* remove invalid -I option from director arguments for now.
* fix paths to executables so debug_test will work with installed versions by default
the previous version was using the src tree locations but basedir was wrong for that.
That test was intended to test the keywords '__extension__' and
'__typeof'. The GCC builtin functions were just a side-effect.
These built-in functions generated error messages on platforms such as
amd64 where sizeof(long double) != sizeof(double), but not on others
such as sparc.
The current infrastructure for the lint tests cannot handle tests with
platform-dependent outcome.
On 32-bit platforms such as i386 and sparc, sizeof(int) == sizeof(long),
which produced an additional unintended lint error message:
msg_130.c(78): error: duplicate case in switch: 4 [199]
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.
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.
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)..
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.
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.
Seen on sparc64 in hdtoa.c:341 since sparc64 is one of the platforms
that has 128-bit long double and defines struct ieee_ext.ext_frach:48
based on uint64_t, which is a GCC extension. Plain C99 only allows
_Bool, signed int and unsigned int as base type for bit-fields.
These types are explicitly allowed by GCC.
I'm not sure which of the flags -g and -p should be stronger. That is,
if both -g and -p are given, should 'unsigned char' be allowed as a
bit-field type since -g would allow it, or should it be warned about
since -p warns about it? For now, continue to warn about these.
The whole purpose of this test is to try the message about invalid
bit-field types in GCC mode. Therefore, use the default lint1-flags
that include -g.
mcf