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.
SetErrorVars can now set .ERROR_EXIT which allows
a .ERROR target to ignore the case of .ERROR_EXIT == 6
which means failure happened elsewhere.
Reviewed by:
reimplement most of this function using a new method of buffer
management to ensure that we never read beyond the provided size.
properly handle RIFF chunk lengths, instead of assuming various
offsets from most files are right.
update list of consumed documentation and fill the list of WAVE
formats from RFC 2361 (most remain not supported.)
should fix PR#57973.
tested against a large number of .wav files i have handy and with
a testsuite generator that should be incoming soon.
Use the same style of quotes for both kinds of variables. To make the
variable values more easily comparable, write them to a single line.
Add the output to the 'expect' lines.
Repurpose message 362, as the previous version was redundant since null
bytes in old-style formats are already covered by message 371 (bit
position out of range) and 377 (redundant '\0' at the end).
The functions snprintb and snprintb_m are specific to NetBSD, and their
format strings are tricky to get correct. Provide some assistance in
catching the most common mistakes.
Pass target scope to Var_ReexportVars so that a target process
will see the correct values in its env.
We must then mark any Global scope variable as unexported
so targets without local value get the Global one.
Use "tracepoint" consistently, rather than a mix with "trace point",
sometimes in the same paragraph. "Breakpoint" and "tracepoint" are
most commonly rendered without the space in tech documentation, AFAIK.
Redo the previous correctly, the test should be whether or not only the
bottom 32 bits are set, rather than whether any of bits 32..63 are set.
This makes no difference if u_long (or unsigned long long) is 64 bits,
it is the same test in that case, but if u_long were 128 bits there is
a notable difference (though for the particular issue observed in the PR,
it is likely to work either way).
chmod/chown/chgrp (probably others) in the not too far distant past,
and causes the operation to be a no-op if no actual change would be
made (avoiding updating the file's ctime for no reason).
That is, with touch, -D causes no modifying sys call to be made to
a file if that file's atime and mtime are already set to the values
that would be used. A common case for this is when a "-r ref-file"
is also a target file for the operation.
Unfortunately -d was already taken in touch, so next best available is -D.
is a symbolic link, the times to use are taken from those of the symbolic
link itself, instead of from the file it references. If the reference file
is not a symbolic link, -R and -r are identical.
This allows the BUGS entry in the manual page to be removed.
fractional seconds. (Alternate ways to achieve that for the other
ways of specifying the date and time may be forthcoming in a future
update).
Also add a warning about the (still far) future likely change of
the interpretation of 2 digit years (the coming POSIX standard
contains a similar warning).
While here, clean up wording, some macro usage, etc etc etc...
alter any of the material fields of the struct tm that was handed
to it. If any were altered, then the time string passed in was
not a valid time representation, and so should be rejected.
This one is not an invisible change, it prevents use of things like
"-t 202402300000" (which previously would have been interpreted as
"-t 202403010000" - the day after the 29th of Feb in 2024).
I believe this is an improvement however, and in line with the
general intent that if you specify a date and time, that exact
date and time is what touch should be using. It does mean that
specifying "60" for the seconds field is almost guaranteed to
fail on any POSIX system, as leap seconds simply don't exist
there (on a non-POSIX-conforming system that uses leap seconds,
the :60 should work, if specified with the correct date and time
at which the leap second actually occurs).
The one exception is when parsedate(3) is used, as that does not
do this check (which allows things like "-1 day" on the 1st of
a month to work).
(This is the last of this sequence of updates to touch.c, an
update to touch.1 follows).
Previously we have hacked that using parsedate(3) - but parsedate()
returns a time_t and consequently while it "handles" fractional seconds,
all that meant (all it really can mean) is that they're ignored.
The POSIX spec expects that (at least if the filesystem supports them)
fractional seconds can be set using the -d option.
Handle that by first attempting to parse the -d arg as a posix format
date-time string (using a reasonably strict parser), and if that fails,
then fall back on parsedate(3) to parse the arg.
If the posix format parse succeeds, the result will be the same as
parsedate(3) would return for the same string - except any fractional
seconds will be handled properly. If it fails, then nothing changes
from what we currently do.
Note the POSIX string is
YYYY-MM-DDThh:mm:ss[.frac][Z]
where YYYY is (at least) 4 digits (leading 0's are acceptable if
you really must!) all the MM DD hh mm ss fields are exactly 2
digits, T is either 'T' or ' ', '.' is either itself, or ',',
and 'frac' is one or more digits. Z (if given) is 'Z'. The
[.,]frac and Z fields are optional. Specify a time in a
slight shorthand like 2024-2-8T7:44:20 and the POSIX parse
will fail, leaving parsedate() to handle that (which it should).
But any fractional seconds which were given would be ignored.
Doc update coming - note the doc will call the YYYY field CCYY
instead, that's just a convenience to make other parts of what
is there make more sense - it is still one 4 (or more) digit field.
This should be an almost invisible change.
to make it simpler to (eventually, many years hence) to change that rule
to be "if year is < NN it is 21xx and if >= NN it is 20xx" instead.
Avoid comparing a time_t to -1 directly, as time_t might be unsigned.
Instead define NO_TIME as ((time_t)-1) and compare with that instead.
This makes no difference at all when time_t is signed (as it is on
NetBSD).
Use "ss" rather than "SS" as the seconds indicators (in messages)
to match with hh (hours) and mm (minutes) rather than looking like
some relation to YY (year) MM (month) and DD (day). Why this was
ever written as SS is beyond me, but it has been that way forever.
(doc update will follow).
Minor improvement to the error message if the arg to a -t option
is unable to be parsed correctly.
NMFCI (No meaningful...)
The toggles INCLUDES, LIBRARIES, POSIX, SYSVINCLUDE, SYSVVARSUB,
GMAKEEXPORT and SUNSHCMD are no longer needed, they were unconditionally
set.
The toggle NO_REGEX was configurable from the command line, but
disabling it would result in various error messages about the unknown
':C' modifier.
OK sjg@.
By replacing block comments with end-of-line comments, the comments take
up less space and thus no longer require to be indented by 6 spaces.
The messages and their comments are used in 3 places: the manual page
lint.7, the err-msgs.h header for debug mode, and check-msgs.lua to
verify that the comments above the message IDs correspond to the actual
messages.
No functional change.
From a user's perspective, it's irrelevant whether a lint message is
generated using '%s' or '%.*s'; same for the integer widths, as they are
platform-dependent.
Previously, the arguments of a function call expression were arranged in
a linear tree structure, from right to left. To allow easier access to
the arguments, store them in an array instead.
Previously, the ':S', ':ts', ':tA' and ':from=to' modifiers were
evaluated in parse-only mode, unnecessarily. This is only noticeable
when an indirect modifier is evaluated in parse-only mode, which is
another bug that will be fixed in a follow-up commit.
The debug output contained too many newlines.
The buffer functions were built into lint2 even though they weren't
used.
Enable the query for invisible characters in string literals, to make
sure that a newline in a string literal does not trigger that query.
The plain char literals are needed for checking printf/scanf format
strings; lint has no similar check for wide strings. These format
strings are checked by modern compilers, making this check less
relevant.
An integer constant that is signed in traditional C but unsigned since
C90 is an edge case that should not clutter the main code of determining
the resulting type of the constant.
The code for lexing an integer constant doesn't implement the C99 rules
yet, which convert a constant to the 'long long' types if the 'long'
types don't suffice.
It was confusing to have two kinds of "symbol type" (s_type and s_symt),
so rename all related identifiers to be more distinctive.
No functional change.
These were leftovers from splitting large functions into smaller
functions, to ensure that variables were not unintentionally reassigned.
Those refactorings are finished, and the extra help from the compiler is
no longer necessary.
No binary change.
This allows to configure lint flags in mk.conf globally for a whole
NetBSD build. Previously, this would have made the build fail due to
missing .ln files.
The previous use case of rerunning lint with or without queries is easy
enough to achieve by doing a 'make clean', in the same way as for lint
warnings.
logic on kernel options so long as those options are not defflag'd or
defparam'd. This works because such options are automatally added to the
IDENT var in the kernel Makefile as a preprocessor define, and the Makefile
can then do an operation like:
.if !empty(IDENT:M-DSOMECOOLCPUOPTION)
CFLAGS+= -mcpu=somecoolcpu
.endif
Unfortunately, this precludes making it possible to generate a compile-time
dependency on SOMECOOLCPUOPTION, or having SOMECOOLCPUOPTION imply another
kernel config option using the normal config(1) option dependency function.
Fix this by introducing a new option description keyword: mkflagvar. This
keyword marks an already defflag'd option as wanting a kernel Makefile var
defined if that option is selected in the kernel config file. So:
defflag opt_coolcpu.h SOMECOOLCPUOPTION ANOTHERCOOLCPUOPTION
mkflagvar SOMECOOLCPUOPTION ANOTHERCOOLCPUOPTION
will cause:
KERNEL_OPT_SOMECOOLCPUOPTION="1"
KERNEL_OPT_ANOTHERCOOLCPUOPTION="1"
...to be emitted into the kernel Makefile if those options are, in fact,
selected with "options ..." in the kernel config file, thus allowing for
a compile-time dependency on the option to be generated in addition to
Makefile logic, which now looks like:
.if !empty(KERNEL_OPT_SOMECOOLCPUOPTION)
CFLAGS+= -mcpu=somecoolcpu
.endif
rillig