scsh-users
[Top] [All Lists]

Scsh 0.5.1 regexp operations: Bug Report and Patch

To: scsh-bugs@martigny.ai.mit.edu
Subject: Scsh 0.5.1 regexp operations: Bug Report and Patch
From: euler@lavielle.com (Lutz Euler)
Date: Thu, 18 Mar 1999 12:35:34 +0100 (MET)
Following up my mail from Feb 11:

> Message-ID: <14018.48241.205289.196067@euler-pc>
> To: scsh-bugs@martigny.ai.mit.edu
> Subject: Bug in string operations (format?) under Solaris x86
>
> Scsh 0.5.1, under Solaris 2.6 or 2.4 on Intel x86 processor,
> shows some strange behaviour:
> > ((infix-splitter "\n") (format #f "~a" "\n\n\n"))
> Error: exception

I traced the problem down to a bug in the regular expression matcher.
Under some conditions the function "regexec" in "scsh/regexp/regexp.c"
would read beyond the end of the string, possibly producing wrong matches.

To reproduce the problem:
Make an empty string with a null byte after the terminating null byte:
> (define s (string (ascii->char 0) (ascii->char 0)))
> s
"^@^@"
> (string-match "a" s)
#f                  ;; Correct
Make an empty string with an "a" character after the terminating null byte:
> (define s (string (ascii->char 0) #\a))
> s
"^@a"
> (string-match "a" s)
'#{regexp-match}    ;; Incorrect

A patch is supplied below. I have checked that it cures the above problem and
have also successfully run the regexp regression tests on the patched source.

As an aside: "regexp-exec" does not check the optional "start" parameter
against the string length. Is this deliberately done or an omission?
Wouldn't it be better if it returned no match or signal an error?

Lutz Euler
-- 
"Lavielle" EDV Systemberatung GmbH & Co. KG   Tel.:  ++49 40 / 658088
Lotharstrasse 2b, D-22041 Hamburg             Fax.:  ++49 40 / 65808-202
http://www.lavielle.de/                       Email: euler@lavielle.com

Attachment: scsh-0.5.1-patch1
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>
  • Scsh 0.5.1 regexp operations: Bug Report and Patch, Lutz Euler <=