Previously, the 'INDENT OFF' comments were interpreted when the newline
token from the line above the comment was processed, which was earlier
than could be reasonably expected.
The 'INDENT ON' comments were interpreted equally early, which led to
the situation that the 'INDENT OFF' comments were preserved literally
but the 'INDENT ON' comments weren't.
The indenter did not handle these backslashes well, interpreting them as
unary operators, and they are an edge case anyway. Line continuations
in string literals and character constants are kept.
Remove the need to explicitly initialize the buffers. To avoid
subtracting null pointers or comparing them using '<', migrate the
buffers from the (start, end) form to the (start, len) form. This form
also avoids inconsistencies in whether 'buf.e == buf.s' or 'buf.s ==
buf.e' is used.
Make buffer.st const, to avoid accidental modification of the buffer's
content.
Replace '*buf.e++ = ch' with buf_add_char, to avoid having to keep track
how much unwritten space is left in the buffer. Remove all safety
margins, that is, no more unchecked access to buf.st[-1] or appending
using '*buf.e++'.
Fix line number counting in lex_word for words that contain line breaks.
No functional change.
A comment is not supposed to change the state of the 'blank line after
declaration', but it did. The initialization of saved_just_saw_decl was
wrong though since it tried to capture the previous value after it had
already been overwritten.
This fixes several bugs where blank lines were erroneously added or
removed, treating these old bugs for new bugs in different places.
These new bugs are expected to be easier to fix, as the old bugs will
not interfere anymore.
the pathname matching tests ... this is not used in any way in a normal
test run, but if there are problems, one needs a mechanism to discover
whether the issue is with the code that creates the directory tree in the
test, or with the matching (either what the test expects to happen, or
what the shell actually does). The couple of lines being fixed here make
that mechanism work --- I have had this in my private sources for years
now, but never got around to committing it. It is time. NFC for any
normal test run.
It is not the job of an indenter to swap tokens, even if it's only about
placing comments elsewhere. The code that swapped the tokens was
complicated, buggy and impossible to understand.
In -br (brace right) mode, indent no longer moves a '{' from the
beginning of a line to the end of the previous line, as that was handled
by the token swapping code as well. This change is unintended, but it
will be easier to re-add that now that the code is simpler.
Previously, the type was reported as 'int' instead of 'enum'.
Continue to only report the type simple for pointer types, as the exact
pointer type is irrelevant to this message.
Previously, lint accepted -X '1, 2, 3', while the manual page lists the
IDs without spaces.
On 32-bit platforms, lint accepted -X -4294967295, and on 64-bit
platforms, it accepted the corresponding larger numbers.
The code for parsing message IDs and query IDs conceptually does the
same, but the implementations differed for no reason.
New test case that reflects the fix in PR kern/57260. The majority of
work for this case itself was by riastradh@, who'd supplied the basis
for it in the ticket, and provided further guidance.
https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html
The previous attempt (message 351 about 'extern' declarations outside
headers) did not cover the proposal from the tech-userlevel mailing list
but instead warns about a different usage pattern of the 'extern'
keyword.
to the next instruction. Only ERESTART should return to
the same instruction. Differences to sparc64 reduced.
Test t_ptrace_wait:syscallemu1 now passes on sparc.
Fixes PR kern/52166 "syscallemu does not work on sparc (32-bit)"
Ok: Martin Husemann
to what the shell produces for tilde expansions, when the expansion
of the tilde prefix ends with '/' and the character immediately following
is another '/' - previously /bin/sh (and most other shells, but not all)
retained both slashes, and this test expected that behaviour.
No longer, now only one of the two will appear. Adjust the expected
test results accordingly, and add an extra loop iteration to make sure
this is thoroughly tested (one more tilde expansion value).
Also, add two new test cases that test for the new (explicit - though
it was always stated this way, but not as explicitly) that if HOME is
an empty string (not unset - that remains an unspecified case, as it
was) then the expansion of ~ must generate "", and not nothing.
The current test was unable to distinguish those two, since it
simply looked for characters in the output, so add a new test cases
explicitly to test for this particular case. This also means (also
previously in the standard, but not as explicitly) that shells are
not permitted to decide "The ~ expansion produces an empty string, that
is weird, let's generate something else instead" which some shells were
doing.
For large integer constants, the resulting type could differ between
traditional C and C90. In C99 mode, this difference is no longer
relevant since it is too far away from traditional C.
The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.
Following the C11 grammar, the keyword '_Atomic' needs to be a separate
syntactic category, to avoid further conflicts in the grammar.
The two newly added conflicts in the grammar would come into play when
mixing traditional C with C11, in a type name without an implicit 'int'.
If the type '_Atomic(int)*' were parsed as '_Atomic int(int)*', the
trailing '*' would be a syntax error.
And make the tests work, and exercise all lengths up to 100.
Evidently the previous definition, presumably tightly optimized for
1980s-era compilers and CPUs, was too hard to understand, because it
was incorrectly tested for two decades and broken for years.
PR lib/57141
XXX pullup-8
XXX pullup-9
XXX pullup-10
process scheduling works. That a process (or in this case,
a thread) is no longer blocked at time T does not mean that it
will resume execution at time T. The OS is free to devote
resources to other processes/threads instead - all we should
normally be able to expect is that if it is not unblocked before
time T, that it will not start running before then.
In general though, the pthread_cond_*wait() functions don't guarantee
even that - but for this test, the possibility of something else
randomly signalling the condvar isn't believable, so don't worry about
that possibility (but do fail without calling strerror(0) on the off
chance it does happen).
Once we cease testing that the process resumed running before some
particular time, we can stop dealing with qemu timekeeping issues,
it might (seem to) take qemu twice as long as was requested before
the thread resumes, but that's OK - the same thing could happen on
a loaded system for other reasons.
Beyond that, the test also has (had) a race condition. When using
CLOCK_REALTIME though that clock needed to have advanced to T before
the ETIMEDOUT should happen, there is no guarantee that it will stay >T
(CLOCK_REALTIME is allowed to be reset backwards). So, only test
that the current time (after ETIMEDOUT) >= T when we're using
CLOCK_MONOTONIC - for CLOCK_REALTIME the time might have stepped
back between when the ETIMEDOUT happened and when the thread
obtains the current clock reading. For that case, all we can test
is that the ETIMEDOUT actually happens.
With much of what was there now gone, the code can be simplified,
we no longer need to do timespec arithmetic, just one comparison
(simpler to test that Tend >= Tstart+period than Tend-Tstart > period
as we need Tstart+period for the abstime value for the timeout anyway).
Note that this still tests for the issue reported in PR lib/47703
which is where the test came from in the first place.
ps: we seem to be missing pthread_cond_clockwait() which is the same
as pthread_cond_timedwait() except that the clock to use is passed
as a parameter, rather than as an attribute of the condition variable.
To test e.g., the file "/some/where/protocols" instead of "/etc/protocols",
set TEST_FILE=/some/where/protocols in your environment.
Note: this now compares the contents of the file you gave versus what
getprotoent(3)/getservent(3) uses (which still is /etc/protocols via
h_protoent.c / /etc/services or /var/db/services.cdb via h_servent.c).
When you have expected changes in the services or protocols file that
you're generating, this necessarily produces a difference. To really
allow testing the file versus what the library function returns, you'd
have to install the file on the system running the test, but at least
with this change you can now generate the file and verify that it didn't
caused unexpected differences.
for native /dev and create an alias for disk devices w/o partition
latter pointing at the raw partition, so for rump based tests we
actually have to calculate the concrete device name.
Use an idiom suggested by kre for this which also works for ports that
have kern.rawpartition > 4.
the secondary GPT header is moved. Do it this way rather than
just using -q to suppress the message, so the test verifies that
the appropriate action was taken.
As of:
commit 36c52a52eecf1ed0232f9e138564009a85de76c2
Author: Jonathan T. Looney <jtl@FreeBSD.org>
Date: Sat Nov 14 15:44:28 2020 +0000
Add a regression test for the port-selection behavior fixed in r367680.
disabling support in UFS2 for extended attributes (including ACLs).
Add a new variant of UFS2 called "UFS2ea" that does support extended attributes.
Add new fsck_ffs operations "-c ea" and "-c no-ea" to convert file systems
from UFS2 to UFS2ea and vice-versa (both of which delete all existing extended
attributes in the process).
correct so make the expected return ERR then repeat the call with
scrollok set to true to validate.
Do refreshes on the window instead of stdscr so we get the window
contents reported and update the check files with the expected
output.
error: queries.c(118): missing /* expect+1: implicit conversion
changes sign from 'char' to 'int' [Q3] */
error: queries.c(122): missing /* expect+1: implicit conversion
changes sign from 'char' to 'int' [Q3] */
Declaring an array type having a negative dimension is the simplest way
to embed an integer into a lint diagnostic, thereby revealing what size
and alignment lint has calculated for a struct.
While here, move these "compile-time assertions" closer to their
corresponding struct, to make reading easier.
In the kernel, several structs have this attribute, and running lint on
them runs into a compile-time assertion. Typical error messages are:
* error: illegal bit-field size: 255 [36]
* error: integral constant expression expected [55]
Most GCC attributes consist of a single identifier. Up to now, it was
necessary to list each of these identifiers in the grammar, even those
that only apply to a single target architecture.
Instead, parse the general form of attributes, matching the few
attributes that lint handles by name instead. While here, rename the
grammar rules to use the GCC terms.
To avoid conflicts between the global function 'printf' and the GCC
attribute of the same name, do not add GCC attributes to the symbol
table, and don't make these symbols 'extern' either.
ok christos@.
cgdconfig: getfsspecname failed: no match for `wd0e'
as the virtual machine has root on dk0, dk0 at wd0 and trying to
open wd0e fails.
This tests runs without a rump kernel and therefore should not
even try to open configured devices on the host. Replace the
disks "wd0e" and "ld1e" with non-existant disks "dska" and "dskb".
New clause `shared <id> algorithm <alg> subkey <info>' in a keygen
block enables `cgdconfig -C' to reuse a key between different params
files, so you can, e.g., use a single password for multiple disks.
This is better than simply caching the password itself because:
- Hashing the password is expensive, so it should only be done once.
Suppose your budget is time t before you get bored, and you
calibrate password hash parameters to unlock n disks before you get
bored waiting for `cgdconfig -C'.
. With n password hashings the adversary's cost goes up only by a
factor of t/n.
. With one password hashing and n subkeys the adversary's cost goes
up by a factor of n.
And if you ever add a disk, rehashing it will make `cgdconfig -C'
go over budget, whereas another subkey adds negligible cost to you.
- Subkeys work for other types of keygen blocks, like shell_cmd,
which could be used to get a key from a hardware token that needs a
button press.
The <info> parameter must be different for each params file;
everything else in the keygen block must be the same. With this
clause, the keygen block determines a shared key used only to derive
keys; the actual key used by cgdconfig is derived from the shared key
by the specified algorithm.
The only supported algorithm is hkdf-hmac-sha256, which uses
HKDF-Expand of RFC 5869 instantiated with SHA-256.
Example:
algorithm aes-cbc;
iv-method encblkno1;
keylength 128;
verify_method none;
keygen pkcs5_pbkdf2/sha1 {
iterations 39361;
salt AAAAgMoHiYonye6KogdYJAobCHE=;
shared "pw" algorithm hkdf-hmac-sha256
subkey AAAAgFlw0BMQ5gY+haYkZ6JC+yY=;
};
The key used for this disk will be derived by
HKDF-HMAC-SHA256_k(WXDQExDmBj6FpiRnokL7Jg==),
where k is the outcome of PBKDF2-SHA1 with the given parameters.
Note that <info> encodes a four-byte prefix giving the big-endian
length in bits of the info argument to HKDF, just like all other bit
strings in cgdconfig parameters files.
If you have multiple disks configured using the same keygen block
except for the info parameter, `cgdconfig -C' will only prompt once
for your passphrase, generate a shared key k with PBKDF2 as usual,
and then reuse it for each of the disks.
Note that realpath can act differently for root than for other users
(where an ordinary user will see EACCESS root just barrels right through).
The tests adapt themselves, when run as root, less error cases can be
tested than when run as some other user.
The previous message 'may cause alignment problem' was not detailed
enough to be actionable, it didn't give the necessary insight to why
lint was complaining at all.
The new message 'increases alignment from 1 to 4' or 'from 2 to 8'
describes the potentially problematic conversion, and together with the
involved type names, it allows an informed decision about whether lint's
warning is warranted or not.
In a typical NetBSD build, this warning is in the top 10. The number of
these warnings depends on the architecture, it is typically between 800
and 1600.
Casting from and to _Bool is only allowed outside strict bool mode.
Outside strict bool mode, _Bool is an integer type, therefore return
early if any of the operands has type _Bool. In strict bool mode, even
casting from _Bool to _Bool is not allowed, as it is not needed in
practice.
Handle _Complex types before real floating-point types. Return early
for _Complex types, as these are floating-point types as well.
For pointer casts, not only flag casts to or from 'pointer to void', but
also casts between the same types.
In debug mode, when constructing the type '_Complex float', the type
name of '_Complex' occurs in the debug log. Outside of debug mode,
printing this type name is an error since this type keyword only occurs
internally, when constructing a type. At that point, it is not supposed
to occur in any user-visible message.
rillig