Bad return values from CL-PPCRE

[Philipp Marek]

Short version is: SBCL 1.3.3 on Debian, amd64.

    (print (list
             (cl-ppcre:scan "h" "999" :end 27)
             (cl-ppcre:scan "h" "999" :end 28)
             (cl-ppcre:scan "h" "999" :end 29)
             (cl-ppcre:scan "h" "999" :end 30)
             (cl-ppcre:scan "h" "999" :end nil)
             ))
    (NIL NIL 28 28 72)

ECL and Clisp report errors about index out of range; at least the ":end NIL" call should succeed normally, but say "no match".

[Attila Lendvai (attila-lendvai)]

FYI, there's this:

https://github.com/edicl/cl-ppcre/issues/26

(cl-ppcre has (safety 0) annotations which is not wise)

[Stas Boukarev (stassats)]

As Attila said, this due to safety 0, anything can happen.

[Philipp Marek (philipp-marek)]

Sorry, but shouldn't the right result come out, regardless of any optimization settings?
When using a too-high index into a string - yeah, that may crash with (safety 0); but ":end NIL" should always work, right?

Isn't that a misoptimization, ie. a bug that should be fixed?

[Stas Boukarev (stassats)]

What makes you think that :end nil should work?

[Philipp Marek (philipp-marek)]

Ah, right; the DEFGENERIC has no default values, and the methods all repeat (LENGTH target-string).

Too bad, it would have been easier for a macro that produces calls - especially when using precompiled match functions, which have a mandatory END argument.

Sorry for the noise, I'd hoped for a simpler way ;/

[Attila Lendvai (attila-lendvai)]

FTR, i've created a PR for this: https://github.com/edicl/cl-ppcre/pull/29