Re: Is this legal ANSI CL behaviour?

From: Christopher C. Stacy (cstacy_at_news.dtpq.com)
Date: 10/24/04 

Date: Sun, 24 Oct 2004 20:23:23 GMT

"Thomas Schilling" <tjs_ng@yahoo.de> writes:

> Since I have the general experience that CL is so well-designed that
> when functions are given not-so-sane arguments they are mostly
> defaulted to do the Right Thing (tm).
>
> So this seems to me like a bug in acl62:
>
> CL-USER> (subseq "abcd" 0 40)
> "abcd^@???^E^@?^@abcd^@???^E^@?^@abcd^@???^E^@?^@abcd"
>
> I would have expected it to return "abcd", that is automatically
> realizing that 40 > (length "abcd") and choosing the latter as the
> upper bound. Or at least to signal an error like clisp does.)

I don't think it's an ANSI compliance bug.

It's an error for the programmer to reference past the end of a sequence;
the consequences are undefined. Many implementations signal an error.
Some sequence functions (for example, ELT) "Should signal an error of
type type-error if index is not a valid sequence index for sequence.".

I'm not sure how one easily learns all that using CLHS.
I found it out by starting with the X3J13 cleanup issue
SUBSEQ-OUT-OF-BOUNDS referenced on the SUBSQ.
(I'm therefore not 100% sure myself that it's true.)

Your suggestion of truncating the result sequence to the active length
doesn't seem like better solution. Since SUBSEQ is not documented to
signal an error in this situation, you must not be relying on that to
allow handling of the problem at runtime. Therefore, you must be expecting
that this out-of-bounds situation represents a bug in the program.
I think that returning the semi-garbage answer you see above is actually
slightly more likely to help you debug than returning the truncated answer.
If you want a truncating version of SUBSEQ, you should make the explicit in
your program by giving it a new name.

I do think it would be optimal runtime behaviour if an error were signalled.
I am not sure what the advantage is of not doing so, at normal safety levels.
When the cleanup issue was written, all the "current practice" implementations
signalled an error.

Relevant Pages

  • Re: A perspective on parallelism
    ... No, its not a bug in the pattern description, its a bug in the user source code. ... Now, if we were to split the original sequence down the middle and hand each half to separate threads doing greedy combining, ... You make a decision that "instruction selection will handle upto 64 threads", pick 64 partitions, and run instruction selection on each partition, in parallel or sequentially or some mixture, depending on the number of available resources. ...
    (comp.arch)
  • Re: A perspective on parallelism
    ... you better have a randomization to uncover that bug early ... No, its not a bug in the pattern description, its a bug in the user ... The bug in the pattern had been there since 1994; ... if we were to split the original sequence down the middle and hand ...
    (comp.arch)
  • Re: difference between *ptr++ and ++*ptr ?
    ... I missed the deliberate nature of the bug in your example. ... though of course this leaves "ptr" unchanged. ... the array element to which p points, and also update p to point to ... sequence points, because the "updating" happens "between the previous ...
    (comp.lang.c)
  • Re: reading large fixed-width datasets
    ... avoiding SUBSEQ is precisely why I use the START and END arguments ... to PARSE-INTEGER. ... sequence, but will instead use the given sequence and the indices to ... sequence functions has to be to allow the operation on subsequences ...
    (comp.lang.lisp)
  • Re: Semantics of ==
    ... >> I think the original True is a bug. ... > are a sequence of two elements, the integer 1, and a sequence that's equal ... > sequence w, as far as I can see, even though there is infinite recursion. ... It will raise RuntimeError in Python 2.4. ...
    (comp.lang.python)