442210 - eval() of regular expression string does not work on OS/2 -- "invalid flag after regular expression"

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Martin Sch]

The url javascript:eval('/test/') gives the error message "invalid flag after regular expression" in the error console. In windows, this works.

javascript:eval(/test/) and javascript:new RegExp('test') work fine.

Comment 1

[Peter Weilbacher]

Yes, I can confirm that this is different behavior between the OS/2 version of Firefox 3 and the versions on Linux and Windows. The same goes for SeaMonkey, too. I didn't test with Firefox 2 or SeaMonkey 1.1.x, though. jms, did you?

I looked through the JS code a bit but didn't find anything that would explain this difference. In particular, I didn't see any code branches that would exclude OS/2 and look relevant to this.

Comment 2

[Peter Weilbacher]

I wonder if this another deficiency of our C-library, like bug 396798.

Can someone of the JS gurus tell me where I should start looking in the code?

Comment 3

[Brian Crowder]

There's only one place in jsregexp.c at which JSMSG_BAD_FLAG is reported.  Breaking there and figuring out how we get there would be instructive.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Note that there's also a place in jsscan.cpp that reports this error.

Comment 5

[Brian Crowder]

Oh, good eye mrbkap.  Thanks!

Comment 6

[Martin Sch]

javascript:eval('/test/ ') works fine (extra blank at end)

Comment 7

[Martin Sch]

After scanning the string /test/, we come to line 1844 of jsscan.c:

c = PeekChar(ts);
if (JS7_ISLET(c)) {               /* ((c) < 128 && isalpha(c)) */
  tp->ptr = ts->linebuf.ptr - 1;
  js_ReportCompileErrorNumber(cx, ts, NULL, JSREPORT_ERROR,
                                     JSMSG_BAD_REGEXP_FLAG);
  (void) GetChar(ts);
  goto error;
}

If there is a \0 now, we should not go into the if statement because the  \0 fails the isalpha test.

That means that the string is not null terminated or something is wrong with GetChar/UngetChar.

Comment 8

[Brian Crowder]

Well, what's c?

Comment 9

[Peter Weilbacher]

When running the javascript:eval('/test/') testcase I see that c is EOF, before and after the PeekChar() call that was quoted in comment 7.

Comment 10

[Brendan Eich [:brendan]]

This reminds me of broken Unix libc ports to odd systems. Since c is int, EOF is -1 (check this in your stdio.h). Then you need <ctype.h> to offset the attributes lookup table it uses for isspace, etc., by 1, so indexing by -1 is memory safe and gets the right (0) attrs for EOF.

/be

Comment 11

[Peter Weilbacher]

Thanks, be. I think you nailed the problem. Will try to solve that with the guys who maintain our compiler and C library.

(Now that you say that I also remembered to test with a GCC 3.2.2 compiled build and there this bug doesn't happen.)

Comment 12

[Peter Weilbacher]

OK, confirmed to be a bug outside the Mozilla sources. This is now tracked as a bug of the C-library at <http://svn.netlabs.org/libc/ticket/199>.