The code for $@ depends on reading a_w.w_symbol values, but the other
A_DOLLAR branch (i.e., for $1 - $n) depend on reading a_w.w_index.

So for the conditional at the top of binbuf_eval, this means that any
normal A_DOLLAR that has its a_w.w_index set is actually trying to read
a_w.w_symbol. On a 64-bit arch with certain compilers, this will result
in a read of uninitalized data in the padding of the part of w_symbol
that exceeds the sizeof(int).

The workaround here is to define a sentinel value DOLLARALL to a negative
int unlikely to ever be used in real A_DOLLAR values. We then use DOLLARALL
to mean the "@" in "$@" so we can create a special branch for it in the
parser.

One consequence-- we probably need to add a special case error when
this value is out of range. So rather than confusing the user with the
mysterious negative value of DOLLARALL we print "$@" for them. (Currently,
the only place I can see this happening is when "$@" is used as the
target for a Pd message.)