uncaught exception in stoul

[ldn-softdev]

There's a rare exception that might occurs when doing some walks with RE, e.g.:

bash $ <ab.json jtc -w'<street address>l:<^\d>R:[-2]' 
libc++abi.dylib: terminating with uncaught exception of type std::invalid_argument: stoul: no conversion
Abort trap: 6
bash $ 

the same would not occur if lexemes wasn't iterative, or next offset would be different, e.g.:

bash $ <ab.json jtc -w'<street address>l<^\d>R[-2]' -r
{ "address": { "city": "New York", "postal code": 10012, "state": "NY", "street address": "599 Lafayette St" }, "age": 25, "children": [ "Olivia" ], "name": "John", "phone": [ { "number": "112-555-1234", "type": "mobile" }, { "number": "113-123-2368", "type": "mobile" } ], "spouse": "Martha" }
bash $ 
bash $ <ab.json /jtc -w'<street address>l:<^\d>R:[-1]' -r
{ "city": "New York", "postal code": 10012, "state": "NY", "street address": "599 Lafayette St" }
{ "city": "Seattle", "postal code": 98104, "state": "WA", "street address": "5423 Madison St" }
{ "city": "Denver", "postal code": 80206, "state": "CO", "street address": "6213 E Colfax Ave" }
bash $ 

[ldn-softdev]

Bug analysis:

the bug is a result of a implementation of new enhancements:
a) REGEX supporting template-interpolation
b) auto-generated tokens ($a,$A) for atomic values

the flow of code leading to the bug:
when resolve_ns(..) is called for RE lexeme (when it's iterative, and resolution occurs 2nd time), the argument passes a walk iterator (*this), but it's called from the walk-iterator itself - thus at this moment the walk-iterator is partial (unresolved completely) - it carries a correct path towards currently walked/resolved lexeme (and its label), but the super-node yet holds a prior's walk parent type (which happened to be an Aray).
So, when resolve_ns(..) calls interpolate(..) and the latter in its turn calls generate_auto_tokens_(..): in that call the entry is processed as atomic and an attempt is made to stringify atomic entry's index (because partial super-node indicates it's the Array), but the carried label is in fact a string (of the resolved from the prior lexeme walk-step), thus the attempt to pass a literal value to stoul(..) result in the exception.

Solution:

Add a check to the atomic path in generate_auto_tokens_(..) for presence of {$a}|{$A} tokens: NS for corresponding tokens won't be auto-generated if no such tokens are present in the RE.
However, if such token was present, then a legit regex exception might be thrown:

bash $ <ab.json jtc -w'<street address>l:<^\d{$A}>R:[-1]' 
regexp exception: The expression contained an invalid range in a {} expression.
bash $ 

The exception is legit this time (usage of auto-tokens in REGEX lexemes is unsupported - due to unresolved iterator): 'cause when R lexeme is executed the first time now, the iterator won't be resolved and thus generation of auto-label $A won't happen (corresponding NS won't be generated) - this results that entire RE lexeme ("^\d{$A}") is passed to the regular search which would legitimately complain about such quantifier

The User-Guide will be updated accordingly - auto-tokens are not supported in REGEX lexemes.

[ldn-softdev]

I might harden the solution by making sure that during interpolation called from within resolve_ns (..) the interpolation will skip tokens auto-generation entirely.