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.
The possible values of the expression 'a % b' for unsigned integers lie
between 0 and (b - 1). For signed integers, it's more complicated, so
ignore them for now.
For unsigned integers, the possible range of the result can be narrowed
down by looking at the right operand of the '%'. Right now, lint
doesn't do this though.
In the last 18 months, several lint warnings have been made adjusted to
allow common usage patterns. For example, lint no longer warns about a
constant condition in the statement 'do { ... } while (false)' (message
161), as this pattern is well-known in statement-like macros, making it
unlikely that the 'false' is a mistake. Another example is casts
between unequal pointer types (message 247) for a few well-known
patterns that are unlikely to be bugs.
Occasionally, it is useful to query the code for patterns or events that
would not justify a warning. These patterns are modeled as predefined
queries that can be selected individually, in addition to and
independently of the existing warnings and errors.
New queries can be added as needed, in the same way as new warnings.
Queries that are deemed no longer used can be deactivated in the same
way as warnings that are no longer used.
As long as none of the queries is enabled, they produce a minimal
overhead of querying a single global variable. Computations that are
more expensive than a few machine instructions should be guarded by
any_query_enabled.
https://mail-index.netbsd.org/source-changes-d/2022/06/28/msg013716.html
ok christos@
build_bit_shift converts the right-hand operand to INT or UINT, even
though C11 6.5.7 doesn't say anything about narrowing conversions.
Traditional C says that the operators '<<' and '>>' perform the usual
arithmetic conversions. This has been dropped in C90.
What lint actually does is something completely different. In the
operators table in ops.def, the operators '<<' and '>>' are not marked
as performing the usual arithmetic conversions (column 'balance'). This
leaves all conversions to 'build_bit_shift', which converts the
right-hand side to INT or UINT. There is no obvious reason for this
conversion, as the bounds checks need to be performed no matter whether
the type is INT or UINT128.
Message 138 doesn't occur in practice, it was the last one that was
missing the quotes around the placeholder.
Message 240 was also missing the quotes, but it was not reachable. There
was also no apparent benefit in warning about 'assignment of different
structures' when the message about 'assignment type mismatch' serves the
same purpose.
If the (recursive) element type of the array is compatible, that's good
enough. Even after the previous commits, this warning is the one that
occurs most in a standard NetBSD build, and it is generally ignored.
For now, focus on reducing the number of false positives to an
acceptable level.
Casting a 'pointer to char' to a 'pointer to anything else' is already
allowed, except for 'pointer to struct/union'. The cause for this
inconsistency is the wrong order of checks in
'should_warn_about_pointer_cast'.
Reword some of the messages slightly, exchanging brevity for clarity.
Message 138 is kept as-is, as it is not yet covered by any tests.
Message 240 is kep as-is, as it is unreachable.
rillig