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
When a cast-expression comes partly from a system header, determine at
the ')' whether the whole cast-expression comes from the system header.
Previously, it was based on the operand, which contradicted the
documentation of tn_sys.
Mainly affects strict bool mode (where expressions from system headers
are handled more leniently), as well as query 9 for parenthesized return
expressions.
Discovered upon manual inspection, as calling expr_alloc_tnode should
never be necessary when creating an expression node with operands;
there's build_op for that purpose.
When compiling lint1/cgram.c:
during RTL pass: postreload
cgram.c: In function 'yyparse':
cgram.c:5873:1: internal compiler error: in reload_combine_note_use,
at postreload.c:1534
Both GCC 11 and Clang 8 accept member-designators that are not
identifiers but designator sequences, such as in 'offsetof(struct stat,
st_atim.tv_sec)', so make lint accept them as well.
Move %s: progname from Job_CheckCommands to Fatal
to avoid is being repeated when Job_CheckCommands is passed Error.
This means some errors from var also report progname (and level)
which is useful.
Reviewed by: rillig
PR lib/57798
Digit value specified by TODIGIT is storaged as lowest 8 bits of
_RuneType, see lib/libc/locale/runetype_file.h:
https://nxr.netbsd.org/xref/src/lib/libc/locale/runetype_file.h#56
The symptom reported in the PR is due to missing range check for
this value; values of 256 and above were mistakenly treated as
other flag bits in _RuneType.
For example, U+5146 has numerical value 1000,000,000,000 ==
0xe8d4a51000 where __BITS(30, 31) == _RUNETYPE_SW3 are turned on.
This is why wcwidth(3) returned 3 for this character.
This apparently affected not only character width, but also other
attributes storaged in _RuneType.
IIUC, digit value attributes in _RuneType have never been utilized
until now, but preserve these if digit fits within (0, 256). This
should be safer for pulling this up into netbsd-10. Also, these
attributes may be useful to implement some I18N features as
suggested by uwe@ in the PR.
netbsd-[98] is not affected as these use old UTF-8 ctype definitions.
When LoadFile reads from /dev/null the buffer will be empty,
appending "\n" just results in an unnecessary extra call
to ParseRawLine.
Reviewed by: rillig
Previously, the expression 'a & b' was only treated as bool if 'a' had
enum type. This didn't cover cases in which bit masks were implemented
using integer types instead of enum sets.
All variables from the command line scope have the fromCmd flag set, so
there is no need to check for it.
Inline redundant local variables.
Variables from a scope cannot be short-lived, so there is no need to
call VarFreeShortLived.
No functional change.
PR lib/57798
It was implemented with an assumption that all digit characters
can be mapped to numerical values <= 255.
This is no longer true for Unicode, and results in, e.g., wrong
return values of wcwidth(3) for U+5146 or U+16B60.
As a workaround, neglect TODIGIT for now, as done for OpenBSD:
https://github.com/OpenBSD/src/commit/4efe9bdeb34
XXX
At least netbsd-10 should be fixed, but it requires some tests.
Ensure that make's output is correctly ordered with the output of the
target's commands, even when the output does not go to a terminal.
Reviewed by: rillig
Since .SHELL is potentially used in compat mode as well,
the man page description should not imply it is only used in jobs mode.
Remove path="sh" from shell-sh unit-test - and it would have detected
this bug.
Reviewed by: rillig
When a variable is not modified or not deleted, clearly say so and state
the reason. Use the same style of debug messages everywhere, putting
the word 'ignoring' at the front. Previously, that word sticked out to
the right, but only in some cases.
The message 'delete %s' that occurs above the 'readOnly' looks as if the
variable would indeed be deleted. The wording in the 'readOnly' line is
unclear.
Remove trailing whitespace.
Remove the first line, as it only repeats the filename.
Remove the line numbers, as they are mostly the same as in the original
source file.
The expression ${U:...} was always undefined, as there was no variable
named 'U'; the intended form was ${:U:...}. Due to this typo, the
comments in the tests for the ':S' and the ':C' modifier contradicted
each other.
In the common patterns where '*' is followed by a regular character,
such as in the patterns '*.c' or '*.mk', search the next possible
matching position in a small loop, instead of repeatedly comparing the
first remaining pattern character to all special characters.
Add a table of contents. Group the existing tests into sections. Fix
the pattern of the test for the malformed ':M[\' modifier, now in line
283.
Note that the tests for the pattern characters '*?\' are missing.
It looked suspicious that to check whether a variable was set via the
command line, the variable value would be needed. Moving the debug
diagnostic to the calling function resolved this smell.
A variable from the command line scope is never short-lived, so there's
no need to clean up after accessing the variable.
No functional change.
Fix grammar issue with "Support values" reported in private mail.
Document all file transfer types in "type" and cross-reference that.
Consistency fixes in describing file transfer parameters and types.
Fix some mandoc -Tlint issues (except "useless macro: Tn").
Right now, Substring_Words terminates each word with a '\0', but that's
an implementation detail that is not required by the interface, so don't
rely on it.
getconf(1) add this and SC_PHYS_PAGES.
libc: Use vm.uvmexp2 over vm.meter is it's twice as fast on my setup.
getconf.3: Tidy up wording for SC_PHYS_PAGES.
- Allocate only one struct pipe not two (no need to be bidirectional here).
- Then use f_flag (FREAD/FWRITE) to figure out what to do in the fileops.
- Never wake the other side or acquire long-term (I/O) lock unless needed.
- Whenever possible, defer wakeups until after locks have been released.
- Do some things locklessly in pipe_ioctl() and pipe_poll().
Some notable results:
- -30% latency on a 486DX2/66 doing 1 byte ping-pong within a single process.
- 2.5x less lock contention during "make cleandir" of src on a 48 CPU machine.
- 1.5x bandwith with 1kB messages on the same 48 CPU machine (8kB: same b/w).
In check_expr_misc, the left and right operands of an expression were
accessed even in the case of CON (constant), STRING (string literal) and
NAME (identifier), which led to invalid values in pointer variables.
These invalid values were not used though, but technically they invoked
undefined behavior.
Precede each access to the operands with a check that the expression
indeed has operands, except in those cases where the operand is known to
have operands by only looking at the code of the current function.
Previously, in a '?:' expression with a constant condition, the branch
that is not taken was skipped but any identifiers in there were intended
to be marked as used. In function call expressions, this only worked
for the last argument, as the PUSH operator is not a binary operator
(see ops.def). Cover this case as well.
main.c(416): warning:
call to 'strchr' effectively discards 'const' from argument [346]
Even though C23 turns strchr into a const-generic function, it doesn't
do the same for strtol, so use separate pointers for the current parsing
position and the end of a number, as their constness differs.
If _SC_NPROCESSORS_ONLN is supported; and -j arg is a floating point
number or ends in 'C' compute .MAKE.JOBS as a multiple of _SC_NPROCESSORS_ONLN
Based on a suggestion from des at freebsd.org
Discussed with: rillig, christos
Check if comma is followed by space, otherwise it may lead to overflow in the
output buffer as space might be extra appended to the output buffer without
consuming anything from the input. This condition breaks the assumption that
length(input) >= length(output) while the code relies on it.
Data provided to skin() can be longer than LINEBUF (if same header is provided
multiple times, hfield returns concatenated data).
Thanks to riastradh@ for the review and comments
The function ensures that that buffer is large enough to store the data (if
not, it reallocates it). It doubled the buffer every time the buffer was too
small, but in some cases it wasn't enough, which might lead to heap overflows.
Rewrite of this function handles int overflow scenarios as well as ensures the
buffer is big enough to handle the data.
Thanks riastradh@ for the review and comments
Shift left on large int values was causing an undefined behaviour, fix it by
operating on unsigned int type instead. This patch changes behaviour of the
hash() slightly - if the computed hash is INT_MIN, the function previously
returned 0, but this case is negligible.
The function wordvcmp returned -1 when either of the word vectors was
short; this made the function asymmetric. Since the function is only
used to compare two word vectors for equality, restrict it to this
particular use case.
The workaround is only needed if the time format contains '%s', in all
other cases there is no need to preserve, set and restore the TZ
environment variable. Suggested by sjg@.
Only check for 's' in the format string, not for '%s', to allow for
optional modifiers of the conversion specifier.
Previously, the error message 'Invalid line' showed only the expanded
line, which might or might not show the actual problem. To be more
helpful, add the unexpanded line to the error message in case they
differ.
Remove the special handling of invalid lines that result from merge
conflicts. RCS is not commonly used anymore, and mentioning CVS was too
specific. By echoing the whole line, the patterns '<<<<<<' and '>>>>>>'
are clear enough to hint at the problem.
Some path prefixes can trigger automount, if we want to ignore them
it might be best to check metaIgnorePaths before we call realpath.
If the raw path does not match, check again after realpath.
create a ptrdiff_t offset between the start of an allocation region and
some interesting pointer, so it can be adjusted with this offset after
realloc() returns. for pdisk(), realloc() is a locally inlind malloc()
and free() pair.
for mail(1), this required a little bit more effort as the old pointer
was passed into another file for fix-ups there, and that code needed to
be adjusted for offset vs old pointer usage.
found by GCC 12.
Since tree.c 1.552 from 2023-07-08, lint warned about integer
conversions from 'int' or 'unsigned int' to smaller integer types. This
only affected 32-bit platforms where size_t is 'unsigned int' rather
than 'unsigned long', as on these platforms, the integer ranks of 'int'
and 'long' are the same, see INT_RANK in inittyp.c.
Discovered by lib/libkvm, which fails on i386 when lint generates any
warnings.
this introduces 4 new warning disable flags:
CC_WNO_MISSING_TEMPLATE_KEYWORD
CC_WNO_REGISTER
CC_WNO_STRINGOP_OVERREAD
CC_WNO_ARRAY_BOUNDS
and documents them in README.warnings. of these, the string op
and array bounds are both problematic (real bugs) and also spurious
(not real bugs), and the other 2 are mostly temporary for older
3rd party code.
add some new uses of CC_WNO_STRINGOP_OVERFLOW.
fix m68k build for gallium and GCC 12.
kre