mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-06-29 22:40:34 +02:00
regexec comment fix
* libguile/regex-posix.c (SCM_DEFINE): Remove comment about threadsafety, given that regexec does appear to be threadsafe.
This commit is contained in:
parent
465466ce4d
commit
445837754e
1 changed files with 0 additions and 11 deletions
|
@ -244,17 +244,6 @@ SCM_DEFINE (scm_regexp_exec, "regexp-exec", 2, 2, 0,
|
||||||
"@end table")
|
"@end table")
|
||||||
#define FUNC_NAME s_scm_regexp_exec
|
#define FUNC_NAME s_scm_regexp_exec
|
||||||
{
|
{
|
||||||
/* We used to have an SCM_DEFER_INTS, and then later an
|
|
||||||
SCM_CRITICAL_SECTION_START, around the regexec() call. Can't quite
|
|
||||||
remember what defer ints was for, but a critical section would only be
|
|
||||||
wanted now if we think regexec() is not thread-safe. The posix spec
|
|
||||||
|
|
||||||
http://www.opengroup.org/onlinepubs/009695399/functions/regcomp.html
|
|
||||||
|
|
||||||
reads like regexec is meant to be both thread safe and reentrant
|
|
||||||
(mentioning simultaneous use in threads, and in signal handlers). So
|
|
||||||
for now believe no protection needed. */
|
|
||||||
|
|
||||||
int status, nmatches, offset;
|
int status, nmatches, offset;
|
||||||
regmatch_t *matches;
|
regmatch_t *matches;
|
||||||
char *c_str;
|
char *c_str;
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue