PARSE-INTEGER with :JUNK-ALLOWED true should return a bounding index after trailing whitespaces
Currently, on SBCL, CCL and ECL:
> (parse-integer " 123 ")
123
7
whereas:
> (parse-integer " 123 " :junk-allowed t)
123
5
(in both examples, the passed string has 2 spaces at start and at end).
Expected output in the second case:
> (parse-integer " 123 " :junk-allowed t)
123
7
Although the CLHS is not straightforwardly explicit about the matter, such a behavior is arguably a standard violation.
Relevant passages of the description of PARSE-INTEGER (CLHS 12.2):
-
Optional leading and trailing whitespace[1] is ignored.
at start of the description. This generally applies, regardless of the value of
JUNK-ALLOWED. -
The second value is either the index into the string of the delimiter that terminated the parse, or the upper bounding index of the substring if the parse terminated at the end of the substring (as is always the case if junk-allowed is false).
at the end.
From this, we deduce that PARSE-INTEGER should always skip optional trailing whitespaces, since you can't ignore characters that you have not parsed.
Also, having PARSE-INTEGER always skip trailing whitespaces is valuable in practice, as users can then generally rely on it, reducing special cases and possible confusion (and bugs).