summaryrefslogtreecommitdiff
path: root/libguile/regex-posix.c
diff options
context:
space:
mode:
authorAndy Wingo <wingo@pobox.com>2016-11-01 21:55:16 +0100
committerAndy Wingo <wingo@pobox.com>2016-11-01 21:55:16 +0100
commit445837754eadd0d3912a7977838280e036766845 (patch)
treec0a3e99e4ee2d5e33f2498904553e03ee654bb18 /libguile/regex-posix.c
parent465466ce4dcb0ca10e9efb3d0746fcee11a96b3f (diff)
downloadguile-445837754eadd0d3912a7977838280e036766845.tar.gz
regexec comment fix
* libguile/regex-posix.c (SCM_DEFINE): Remove comment about threadsafety, given that regexec does appear to be threadsafe.
Diffstat (limited to 'libguile/regex-posix.c')
-rw-r--r--libguile/regex-posix.c11
1 files changed, 0 insertions, 11 deletions
diff --git a/libguile/regex-posix.c b/libguile/regex-posix.c
index bec0f89fb..9350fb38b 100644
--- a/libguile/regex-posix.c
+++ b/libguile/regex-posix.c
@@ -244,17 +244,6 @@ SCM_DEFINE (scm_regexp_exec, "regexp-exec", 2, 2, 0,
"@end table")
#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;
regmatch_t *matches;
char *c_str;