If the command line option yus to allow the underscore character in
symbols is NOT selected, then interpret underscore as a new binary
operator meaning to do a left shift of the left side value by the
number of bit positions indicated by the right side value. As for the
arithmetic operators, both values must be literal (numeric constants
or symbols equated to a numeric constant).
mlb-rt11.c: In function 'mlb_rt11_entry':
mlb-rt11.c:284:27: warning: 'ent' may be used uninitialized in this function [-Wmaybe-uninitialized]
buffer_resize(buf, ent->length + 1); /* Make it large enough */
~~~^~~~~~~~
It is spurious because ent gets initialized in the loop above.
If the loop is never executed, this must be because 0 >= mlb->nentries
and NULL is returned, so the buffer_resize() is never reached.
mlb-rsx.c: In function 'mlb_rsx_entry':
mlb-rsx.c:374:23: warning: 'ent' may be used uninitialized in this function [-Wmaybe-uninitialized]
fseek(mlb->fp, ent->position, SEEK_SET);
~~~^~~~~~~~~~
It is spurious because ent gets initialized in the loop above.
If the loop is never executed, this must be because 0 >= mlb->nentries
and NULL is returned, so the fseek() is never reached.
I haven't done much compatibility testing with MACRO11 to check
weirdnesses, but the original functionality is very limied: none
of the mnemonics has operands.
The comment "eat first char of illegal label, else endless loop on
implied .WORD" was no longer true. It did reveal some other small
gotchas, which are corrected now as well.
There was an obscure bug in parse_expr(), used to evaluate 'if df',
where it could skip past the end of the line marker.
If this happened inside an expanded macro, then after that was the
next line...
In other cases it might be worse.
Now that this is fixed, another check for line end junk can be enabled.
which have an general (source) argument and an AC destination.
There are no FPP instrs which have 1 general source arg;
only with 1 general destination (even TSTF).
