These two functions are supposed to model the designator that is used
for initializing structs and arrays. The implementation is still buggy
and does not work at all for C99 designators with multiple names, see
d_init_pop_member.c.
For now, just rename the functions to head in the right direction.
No functional change.
The operator NAME has the name 'name', therefore no special case is
needed.
Having the words 'with type' in the message makes the message easier to
find from the debug log. Given that the operator name is used unquoted,
the log message 'name: int value=111' was nearly impossible to find in
the code.
Replace the '()' with an actual word, to avoid any confusion about
whether the type name might be a function type without prototype.
Reduce the amount of '=' signs, instead use commas to separate the
properties of the node.
No functional change outside debug mode.
The previous name could be too easily confused with the type qualifier
'const'. The operator name is mainly used in the debug log, only
occasionally in the output. Since 'constant' is not a "real" operator,
it probably doesn't occur in messages at all.
The debugging code is needed by the soon-to-be-added proper handling of
array subscript initializers such as '.member[123].member = 12345'.
No functional change.
This way, the code is covered by running 'make lint'. The code from the
grammar is not covered, therefore it still uses int instead of bool in a
few places.
Inline the comparison functions for uint64_t. These functions didn't
add any clarity to the code.
No functional change.
The new name accurately describes the structural element that holds such
properties as the separator character and whether the expression value
is considered a single word. The old name ApplyModifiersState was too
long and was meant as a placeholder anyway, when I introduced it in
var.c 1.236 from 2020-07-03.
This is an edge case that doesn't occur in practice since pretty much
nobody dares to use variable names that contain an actual '$' in their
name. This is not about the fairly common VAR.${param} (as written in
the makefile), but instead about the variable whose name is literally
'VAR.${param}'.
The test demonstrates that after the fix, the variable name is taken
exactly as-is for the simple assignment modifier '::='. There are no
such tests for the modifiers '::+=', '::!=' and '::?=', but that's ok.
The code in ApplyModifier_Assign would look assymetrical and suspicious
enough if one of these modifiers would expand its variable name and the
others wouldn't.
In CLEANUP mode, was originally meant to track memory allocations but is
useful during debugging as well, initialize the list. There is no
distinct constant representing an invalid pointer, otherwise that would
have been an even better choice.
An enum with 32 bits would lead to signed integer overflow anyway, so
that definition is not worth keeping even if it works on typical
2-complement platforms.
The definitions for 2, 4 and 8 enum have been unused for several months
now.
No functional change.
This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.
The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.
There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.
No functional change.
The name 'NONE' described the bit pattern, which was not useful to
understand its meaning. Omitting VARE_WANTRES only parses the
expression, without evaluating any part of it.
No functional change, not even in debug mode since Enum_FlagsToString
always returns "none" for all-bits-unset.
