The spec does not establish any particular constraints to observe in
casting from `YARN` to `NUMB(A)R`. Presently, `lci` checks that the
string consists only of numeric characters prior to attempting the
conversion, halting with an error if it's found not to be the case.
This behavior is often more inconvenient than helpful. Many numeric
strings encountered in the wild are "roughly numeric", and it would be
wise to account for this observation. As a simple example, a user may
be prompted to input a number; in the case of their inadvertently
providing leading or trailing whitespace, a naive program will crash
rather than gracefully extracting the otherwise sensible input.
This patch removes the `isDecString()` function and instead leverages
the `strtoll()` and `strtof()` functions to handle casts from `YARN`
to `NUMBR` and `NUMBAR`, respectively. Thus, strings to be converted
are permitted to contain leading whitespace, and trailing non-numeric
characters are ignored. Additionally, `YARN`s to be cast to `NUMBR`
may lead with `"0"` or `"0x"` to indicate that the string should be
interpreted as an octal or hexadecimal value, respectively.
This change required the modification of several tests which previously
checked that casting an empty or completely non-numeric `YARN` resulted
in an error. These now verify that such a conversion results in a zero
of the appropriate type.
Printing warnings and the like to the standard error stream is common
courtesy, not least because it avoids cluttering the program's output
with diagnostic messages.
Neither the 1.2 specification nor any of the proposals for 1.3 mention
using `INVISIBLE` for this purpose. Nevertheless, the operator and the
behavior described herein have seen sufficiently wide adoption in other
LOLCODE interpreters that I believe `lci` would do well to follow suit.
This patch attempts to be minimally invasive. Rather than adding a new
node type and all that that entails, the `PrintStmtNode` structure now
has a `FILE *` field containing the file to which the node should print
during interpretation. This saves a branch in `interpretPrintStmtNode()`
at the cost of making the structure negligibly larger on most systems.
Adding tests for `INVISIBLE` would require rethinking the test driver,
which presently uses the existence of output on `stderr` to detect that
an "expected error" has occurred. I'll happily try my hand at making the
necessary modifications if this patch comes to be accepted.
It may be the case that operands to `I DUZ` should not undergo
interpolation, but I'm unable to perceive the rationale. In any case,
the fix is simply to pass the argument through `castStringExplicit()`,
which is unlikely to break any existing code.
I considered adding a test, only to discover that `I DUZ` itself is not
presently being tested. I suppose this is probably to do with its being
a future feature, or else that ensuring its proper functionality across
platforms wouldn't be trivial.
In the latter case, the `echo` command is likely to be available in the
vast majority of environments, and is probably the best candidate for
testing this facet of the language.
Justin J. Meza
D.E. Akers
OrdNas
Mark J. Reed