this is not the same as the internal encoding, since the Link Register
is deliberately non-continous from the other general purpose register
values. To handle this, always translate the value into the internal
format.
- in cpu_idle(), ci_intr_depth is always 0, so there is no need to fetch for increment or conditional branch.
- curcpu() is immutable in idle lwp, there is no need to consider KPREEMPT. Therefore, get curcpu() first and keep using it.
- add more comment.
For a very long time now, I had thought that it would be impossible to
undefine global variables during the evaluation of variable expressions.
This is something that the memory management in Var_Parse relies upon,
see the comment 'the value of the variable must not change'.
After several unsuccessful attempts at referring to an already freed
previous value of a variable, today I discovered how to unset a global
variable while evaluating an expression, which has the same effect. To
demonstrate that this use-after-free can reliably crash make, it would
need a memory allocator with a debug mode that never re-allocates the
same memory block after it has been used once. This is something that
jemalloc cannot do at the moment. Valgrind would be another idea, but
that has not been ported to NetBSD.
Undefining a global variable while evaluating an expression is made
possible by an implementation detail of the modifier ':@'. That
modifier undefines the loop variable, without restoring its previous
value, see ApplyModifier_Loop.
By the very old conventions of ODE Make, these loop variables are named
'.V.' and thus do not conflict with variables from other naming
conventions. In NetBSD and pkgsrc, these loop variables are typically
called 'var', sometimes '_var' with a leading underscore, which also
doesn't conflict with the typical form 'VAR' of variables in the global
namespace. Therefore, in practice these loop variables don't interfere
with other variables.
One case that can practically arise is when an outer variable has a
modifier ':@word@${VAR.${word}}@' and one of the referenced variables
uses the same variable name in the modifier, see varmod-loop.mk 1.10
line 91 for a detailed explanation.
By using the ${:@VAR@@} modifier in a place that is evaluated with
cmdline scope, it is not only possible to undefine global variables, it
is possible to undefine cmdline variables as well. When evaluated in a
specific make target, the expression ${:@\@@@} can even be used to
undefine the variable '.TARGET', which will probably crash make with an
assertion failure.
The variable name 'arg' was misleading since after a successful
TryParseTime, it would no longer point to the argument of the variable
modifier, but to the _end_ of the argument. To reduce confusion, use p
instead, like everywhere else. This name is less specific, which is
still better than a wrong name.
Addition is easier than subtraction, and the expression 'word + wordLen'
obviously means 'the end of the word', which was not as easy to spot
before.
No functional change.
These variables all belong to a string variable. Connect them using
FStr, which reduces the number of variables to keep track of.
No functional change.
There was only a single case where this parameter was false. Inline
that case. That was the only case that needed the return value, so
remove that as well.
When
1. there is a global variable containing a dollar in its expanded name
(very unlikely since there are lots of undocumented edge cases that
make variable names containing dollar signs fragile), and
2. after that (unlikely since that requires .MAKEFLAGS instead of a
normal command line)
3. there is a command line variable of the same name (again very
unlikely since that variable name would contain a dollar sign as
well in the expanded form),
the global variable would not be undefined as promised by the comments
since its name was expanded once more than intended.
Because of the two 'very unlikely' above, this edge case hopefully does
not affect any practical use cases.
Note that this is not about VAR.${param} (which has a dollar sign in its
unexpanded form), but about the case where param itself would expand to
a dollar sign, such as after param=$$.
This is a preparation to extract the code for exporting a cmdline
variable. That code differs in several details from the other code in
ExportVar.
No functional change.
Make prevents global variables from being or becoming visible when a
command line variable of the same name is already defined.
There is a double safety net here. Even if the call to Var_DeleteExpand
were removed, there would be no noticeable effect, other than one less
line in the debug log.
No functional change.
On NetBSD 8.0 it still worked. Maybe gcov doesn't support .c files as
arguments anymore. Using the .gcda files works and is more reliable
anyway since it covers the inline functions in the headers as well.
Reported by Weitian LI via GitHub.
Contrary to the patch suggested in [1], still allow the cursor to be
placed to the very right of the text in a line since that is the usual
behavior of text editors.
Split the function substitute() into two parts: one that handles the
curses-specific part of checking whether a substitution is possible at
the current cursor position, and one that performs the actual
substitution. Only the latter is kept in the code section for the
string manipulation functions, the other is moved to the section for
curses code. Having all the curses code in one place reduces the places
that call beep(). Previously, as well as now, there is a single beep
per invalid key before, but that was not obvious from the previous code.
[1]: https://github.com/DragonFlyBSD/DragonFlyBSD/commit/18d09f18cf4c
On both NetBSD and Cygwin, a missing /usr/bin/fortune would previously
continue since popen does not return an error (as /bin/sh is found and
can be executed), so the next chance to catch an error is pclose. At
that point, the shell has already printed an informative error message
about what happened (or what didn't happen), so that cgram does not need
to print an error by itself.
