Since var.c 1.323 from 2020-07-26, modifiers containing unbalanced
braces or parentheses were parsed differently, depending on whether they
were relevant or not.
For example, the expression '${VAR:...}' is enclosed with braces. When
this expression has a modifier ':S,},}},g' that would double each '}' in
that expression, the parser got confused:
If the expression was relevant, the modifier was parsed as usual, taking
into account that the 3 '}' in the modifier are ordinary characters.
If the expression was irrelevant, the parser only counted the '{' and
the '}', without taking into account that a '}' might be escaped by a
'\' or be an ordinary character. Parsing therefore stopped at the first
'}', assuming it would finish the expression '${VAR:S,}'.
This parsing mode of only counting balanced '{' and '}' makes sense for
the modifier ':@var@...@', which expands each word of the expression
using the template from the '...'. These templates tend to be simple
enough that counting the '{' and '}' suffices.
Fetch geometry from disklabel to be consistent.
Use disktab format instead of the normal human-readable output for parsing
the disklabel.
Avoid overflows in size computation.
This error branch was introduced to make the system act, when a USB
serial adapter is yanked, as if the other end had spat out a line
feed in an attempt to wake any sleeping readers so they will stop
using the USB serial port.
This is no longer necessary, because ttycancel will wake them anyway,
and it is actually harmful because it puts stuff in the output queue
(CR LF) that will never be processed, causing subsequent users to
hang trying to open the device.
Problem found and patch tested by tih@.
There appear to have been no callers with wait=1 since NetBSD 1.0
from a cursory search. Let's nix the parameter altogether on the
next kernel revbump. This logic is probably broken anyway in the
presence of ttycancel, which is necessary for, e.g., yanking USB
serial adapters.
The return value of Var_Parse is largely redundant to the returned
string. The idea behind the type VarParseResult was to migrate all call
sites to checking this return value instead of the returned string, but
that hasn't happened. Instead, the additional type only added more
complexity.
There was a single place where that return value was actually used, when
parsing conditions. And even in that case, ignoring the VarParseResult
added back an error message that previously hid bugs, in the test
cond-token-plain.mk.
Even though these error messages are redundant in the other tests, they
don't hurt as they don't happen often.
uwe