Parser: accept exprs like `$$0++--`.

[Alonely0]

Title. Isomorphic expressions also fail to parse. These should parse the same way we currently accept $($0++)--. This is a bug because GNU AWK does accept them, but very amusingly, their docs give it as an example of an incorrect expression:

Also, operators cannot be combined in a way that violates the precedence rules; for example, $$0++-- is not a valid expression because the first $ has higher precedence than the ++; to avoid the problem the expression can be rewritten as $($0++)--.

Thus, and if possible, I would like the patch to be easily revertible.

[mogando668]

This kind of construct $$0++-- is very very dangerous, even when mawk's are willing to parse and run them just fine.

mawk 'BEGIN { $0 = 3^33; $$0++-- }'

That alone is all you need to crash anything short of machines that show up on LINPACK 500, because awks must materialize every single field in between $1 and $NF. 8^9 alone already took gawk 2.684 secs (using the parens version), while 3^33 is even larger than 8^17 (and the times exponentially worsen from here on, esp once disk swapping kicks in.

ps : for 3^33, even if we're charging an ultra unrealistic resource cost of 1 bit / field, that's 632 TeraBytes of RAM needed just to place hold for all the fields in between $1 and the one being post-decremented. Most high end workstations don't even have 632 TB of SSD, let alone 632 TB of RAM.

[Alonely0]

I was thinking of lazily loading fields for large inputs, which could cut down on this significantly (if not completely). However, we are in the same situation bash is with respect to fork bombs, so I'd guess there's not much we can do other than print a warning for absurd field number queries. Is there something else you'd suggest?