Lisp HUG Maillist Archive

Possible string/= non-conformance

Hello lispworkers,

Here is an excerpt from CLHS describing the string family of functions:

string/= string1 string2 &key start1 end1 start2 end2 
  => mismatch-index
....snip...
  The inequality functions return a mismatch-index that is true
  if the strings are not equal, or false otherwise.
  When the mismatch-index is true, it is an integer representing
  the first character position at which the two substrings differ,
  as an offset from the beginning of string1. 

But in LWW 4.4, I have got the following:

CL-USER 6 > (string/= "on" "one")
T
CL-USER 8 > (string/= "one" "on")
T
CL-USER 7 > (mismatch "on" "one")
2

Is not this behavior conformant?
--
Sincerely,
Dmitri Ivanov
lisp.ystok.ru


Re: Possible string/= non-conformance

You appear to have found a bug in LispWorks. I agree with your reading 
of the spec. Both MCL and OpenMCL produce "2" as the result for your 
first two cases.

  - Stoney

On Feb 26, 2005, at 1:10 AM, Dmitri Ivanov wrote:

> Hello lispworkers,
>
> Here is an excerpt from CLHS describing the string family of functions:
>
> string/= string1 string2 &key start1 end1 start2 end2
>   => mismatch-index
> ...snip...
>   The inequality functions return a mismatch-index that is true
>   if the strings are not equal, or false otherwise.
>   When the mismatch-index is true, it is an integer representing
>   the first character position at which the two substrings differ,
>   as an offset from the beginning of string1.
>
> But in LWW 4.4, I have got the following:
>
> CL-USER 6 > (string/= "on" "one")
> T
> CL-USER 8 > (string/= "one" "on")
> T
> CL-USER 7 > (mismatch "on" "one")
> 2
>
> Is not this behavior conformant?
> --
> Sincerely,
> Dmitri Ivanov
> lisp.ystok.ru
>


Updated at: 2020-12-10 08:53 UTC