Even though 0 is not a boolean constant, allow this common idiom, to
help in those cases where the C preprocessor used by lint does not mark
tokens as coming from system headers (Clang).
To access yytext from lex.c, the lexer needs to be in %pointer mode,
which was specified in IEEE Std 1003.1, 2004 Edition and thus should be
old enough to be available on platforms other than NetBSD, for use in
tools/lint1 where lint1 is built before yacc and lex.
The Clang preprocessor does not mark sections from system headers.
Lint's strict bool mode relies on these markers to allow the functions
from <ctype.h> to be used as 'bool', even though their declared return
type is 'int'. Without these markers, lint complains that the "right
operand of '&&' must be bool, not 'int'". Until this is fixed in lint,
disable strict bool mode.
Not all variables that start with '.' are internals,
and unless they are explicitly flagged as internal should go
into .MAKEOVERRIDES
Update varname-dot-makeoverrides to check this.
Also avoid using SCOPE_CMDLINE when ReadOnly will do.
All changes to the global variable 'dcs' are tracked now, to help
identify the cause of the failing tests in expr_sizeof and
gcc_attribute_aligned.
While here, test more invalid type combinations in typedefs.
While measuring the alignment in bits makes sense when building a struct
type with bit-fields, in all other places it is more confusing than
helpful.
The only visible change is that in debug mode, the format of type sizes
and alignment changed. Since the size of all complete types is a
multiple of a byte (as defined in the C standard), sizes and alignments
are reported in bytes as well. Only while a struct is being built, the
type size may include an additional '+x' for the bits of a bit-field.
The macro 'offsetof(t, m)' already expanded to a constant expression for
scalar members but not for arrays. This was because the macro expanded
to '(size_t)(((t *)0)->m)', which lint internally represents as
'addr(indir(ptr(0) + offset(m)))', and build_address simplifies
'addr(indir(x))' to 'x' if the types match. The types only match for
scalar types though, but not for arrays.
When build_address happens, the type information is incomplete,
therefore 'offsetof(t, array)' has to be simplified at a later point.
Since Dir_FindFile is used by '.include' and its variants,
and will first search .CURDIR unless the give path starts with
".DOTLAST".
Update unit-tests/opt-m-include-dir to test this.
When an expression is evaluated, the resulting text is short-lived in
almost all cases. In particular, the compaction neither affects the
target names nor the global variable values, which are the prime
candidates for permanent memory usage.
The previous expression didn't cause any bug, as the modifier
':@VAR@loop@' changed the value of the expression, thus making the
expression independent from the variable value.
Instead, the variable needs to be deleted from within an indirect
modifier, and that modifier needs to evaluate to an empty string, thus
doing nothing and preserving the original expression value.
Trim down the comments in the archive module, as they mainly repeated
the code. Trim down the binary code size in the archive module, as it
is rarely used.
In Var_Parse, delay two variable assignments until they are actually
needed.
The :gmtime and :localtime modifiers are not used often and thus are not
time-critical. Exchange the custom code that parses an integer from a
substring for an additional memory allocation.
Thanks sjg@ for suggesting to avoid the custom parsing code.
The function TryParseTime takes a pointer to a string, but the LazyBuf
returns a Substring, which is not guaranteed to be null-terminated or
delimited. In TryParseTime, calling strtoul on the Substring read past
the end of the substring.
Noticed in the NetBSD build in libntp, where the :gmtime modifier is
used in two places with the same timestamp value, of which the first was
evaluated correctly and the second wasn't.
The bug was introduced in var.c 1.1050 from 2023-05-09, when the
argument of the :gmtime and :localtime modifiers was allowed to be an
expression instead of an integer constant.
While here, re-enable lint in those cases where lint was skipped due to
a bug in interpreting abstract types, which was fixed in cgram.y 1.469
from 2023-08-02.
Previously, whether the character range '[a-ä]' matched, depended on the
signedness of the plain 'char' type. Since make operates on byte
strings and does not support UTF-8 or other multi-byte character
encodings, this edge case is not expected to occur in practice.
No change in the unit tests as this edge case is not covered by tests.
Ensure we break ties in every case. This way, even though we use the
unstable qsort(3) library routine, the output is reproducible, no
matter what algorithm is behind qsort(3).
It would be nice if we could just use a stable sort function here,
but mergesort(3) is nonstandard, so we'd have to add it to
tools/compat, which is a big pain.
Instead, put a tie-breaking rule in every comparison function we use
with qsort, and abort() in the event of ties -- that way, we noisily
refuse to rely on unstable sort order.
While here, dispense with any question of integer overflow, and
sprinkle comments.
PR bin/58115
On Cygwin, the path '/././..././' is normalized before being passed to
the child 'make' process. Since overly long pathnames are not required
to be supported on all platforms, remove the test.
1. For tools that use elftoolchain: always use elftoolchain's
elfdefinitions.h. Don't even think about looking at the host's
sys/exec_elf.h, which makes no sense and should never happen.
(ELF tools that don't use elftoolchain, like m68k-elf2coff,
continue to use nbincludes/sys/exec_elf.h. But no more nbincludes
hacks in elftoolchain.)
2. For kernel components (solaris, zfs, dtrace): always use
sys/exec_elf.h, even in Solaris components via sys/elf.h.
elfdefinitions.h is not wired up in the kernel build at all.
3. For most userland components that involve libelf: use
elfdefinitions.h via libelf header files (libelf.h, gelf.h).
libdtrace in particular requires _all_ R_* reloc type definitions,
but sys/exec_elf.h brings in only the _current machine's_ R_*
reloc type definitions. (While here: Use uintptr_t instead of
Elf_Addr for pointer-to-integer cast, since Elf_Addr is MD and
provided only by sys/exec_elf.h, not by elfdefinitions.h.)
And most userland components using libelf don't rely on any
properties of the current machine from sys/exec_elf.h, so they can
use libelf's elfdefinition.h.
Exceptions:
- dtrace drti.c relies on link.h -> link_elf.h -> sys/exec_elf.h,
but it also relies on sys/dtrace.h -> sys/elf.h ->
elfdefinitions.h like other userland components using sys/elf.h.
- kdump-ioctl.c uses sys/exec_elf.h directly and sys/dtrace.h ->
sys/elf.h -> elfdefinitions like other userland components using
sys/elf.h.
- t_ptrace_wait.c (via t_ptrace_core_wait.h) uses libelf to parse
core files, but relies on sys/exec_elf.h for struct
netbsd_elfcore_procinfo.
None of these exceptions needs all R_* reloc type definitions, so
as a workaround, we can just suppress libelf's elfdefinitions.h by
defining _SYS_ELFDEFINITIONS_H_ and use sys/exec_elf.h in these
exceptions.
And undo the whole BUILTIN_ELF_HEADERS mistake. This was:
- half bogus workarounds for missing build_install dependencies in
tools/Makefile, which are no longer missing now, and
- half futile attempt to use src/sys/sys/exec_elf.h via nbincludes in
tools involving libelf instead of libelf's elfdefinitions.h, which
collides.
Longer-term, we may wish to unify sys/exec_elf.h and libelf's
elfdefinitions.h, so we don't have to play these games.
But at least now the games are limited to three .c files (one of
which is generated by Makefile.ioctl-c), rather than haphazardly
applied tree-wide by monstrous kludges in widely used .h files with
broken hackarounds to get the tools build lurching to completion.
The C standards do not specify a fixed type for an array subscript, it
just has to be an integer type. Previously, query 4 fired for the
ubiquitous expression 'ptr[sz]' when sz had type 'size_t'.
The test platform_ilp32_long is unaffected by this change, as the
integer constant 0x80000000 has type 'unsigned int', while size_t is
'unsigned long' on those platforms, and even though the types 'unsigned
int' and 'unsigned long' have the same value space, there's still a
conversion, at least for now.
Previously, arguments of incomplete type or 'void' cleared all arguments
of the function call expression, requiring extra checks in later checks.
Invalid function calls are now exported to the .ln files, but that's
irrelevant in practice as these invalid function calls make lint1 fail,
after which xlint removes the .ln file.
what was in 1.50 (while silencing LINT) - it was clearly not the
correct change to make. The code used !FLAG_POUND where it
clearly meant ~FLAG_POUND ... the former is 0, so &= 0 could
be replaced by =0 changing nothing. But that's not what it
should have been doing, other flags should not have been
removed here, just FLAG_POUND.
This problem seems to have existed since support for %#s
was first added in 2011, which kind of suggests how rarely
that format, particularly with other flags (like %#-s)
has ever been used (with no other flags, the bug would not
be noticed).
using "const char search[4]" as a function parameter means that
"search" is actually a pointer type so "sizeof search" returns
8 on 64-bit platforms. i mis-read this and used "sizeof *search"
which is always 1, noted by rillig.
instead of trying to avoid writing "4" twice, put it in a define
and use that in various places instead. annoying.
put the code to find RIFF chunks into a new find_riff_chunk() function,
and handle mis-aligned chunk lengths. can now play files with chunks
that say they are 7 bytes long, and have 1 byte padding.
add some -V -V extra-verbose for the wav parser.
Previously, an unsigned operation that had a negative result went
undetected in a few cases. Now, all results that are not representable
by their type are considered overflows.
The implementation of signed shift-right had been wrong for a few
commits.
rillig