* regexp-exec critcial section errors
@ 2007-01-13 22:24 Kevin Ryde
2007-01-18 13:58 ` Han-Wen Nienhuys
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Ryde @ 2007-01-13 22:24 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
In regexp-exec in 1.8, a nul in the input string, or a bad flags arg,
results in a throw from a critical section, which calls abort(). Eg.
(regexp-exec (make-regexp "x") "\0")
=> abort
(regexp-exec (make-regexp "x") "hello" 0 'badflags)
=> abort
What's the reason for the critical section? Do we think regexec() is
not reentrant? It looks like a conversion from SCM_DEFER_INTS in past
versions, if that suggests anything about it.
I struck this when running a regexp search on some file data that
slightly unexpectedly had nuls in it. I think I was using 1.6 last
time I did the same thing. I guess that version silently ignores past
the nul. Maybe that should get a check, though there's probably a
zillion libc calls that would really ought to have the same.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: regex-posix.c.critical.diff --]
[-- Type: text/x-diff, Size: 636 bytes --]
--- regex-posix.c.~1.78.2.1.~ 2006-02-14 08:59:02.000000000 +1100
+++ regex-posix.c 2007-01-13 12:53:32.000000000 +1100
@@ -245,7 +245,6 @@
whole regexp, so add 1 to nmatches. */
nmatches = SCM_RGX(rx)->re_nsub + 1;
- SCM_CRITICAL_SECTION_START;
matches = scm_malloc (sizeof (regmatch_t) * nmatches);
c_str = scm_to_locale_string (substr);
status = regexec (SCM_RGX (rx), c_str, nmatches, matches,
@@ -269,7 +268,6 @@
scm_from_long (matches[i].rm_eo + offset)));
}
free (matches);
- SCM_CRITICAL_SECTION_END;
if (status != 0 && status != REG_NOMATCH)
scm_error_scm (scm_regexp_error_key,
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: regexp-exec critcial section errors
2007-01-13 22:24 regexp-exec critcial section errors Kevin Ryde
@ 2007-01-18 13:58 ` Han-Wen Nienhuys
2007-01-18 23:07 ` Kevin Ryde
0 siblings, 1 reply; 3+ messages in thread
From: Han-Wen Nienhuys @ 2007-01-18 13:58 UTC (permalink / raw)
Kevin Ryde escreveu:
> In regexp-exec in 1.8, a nul in the input string, or a bad flags arg,
> results in a throw from a critical section, which calls abort(). Eg.
>
> (regexp-exec (make-regexp "x") "\0")
> => abort
>
> (regexp-exec (make-regexp "x") "hello" 0 'badflags)
> => abort
>
> What's the reason for the critical section? Do we think regexec() is
> not reentrant? It looks like a conversion from SCM_DEFER_INTS in past
> versions, if that suggests anything about it.
>
> I struck this when running a regexp search on some file data that
> slightly unexpectedly had nuls in it. I think I was using 1.6 last
> time I did the same thing. I guess that version silently ignores past
> the nul. Maybe that should get a check, though there's probably a
> zillion libc calls that would really ought to have the same.
Ehm,
I get
**
Running reader.test
Running receive.test
Running regexp.test
ERROR: Unbound variable: exception:string-contains-nul
FAIL: check-guile
==================================
**
it might be a good idea to have an autobuild daemon that compiles and
checks the test-suite.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-01-18 23:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-13 22:24 regexp-exec critcial section errors Kevin Ryde
2007-01-18 13:58 ` Han-Wen Nienhuys
2007-01-18 23:07 ` Kevin Ryde
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).