bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`
Ludovic Courtès writes: > Hi Andreas, > > And welcome back! :-) > Thanks -- and thanks in return for looking into this! > Andreas Rottmann skribis: > >> Andreas Rottmann writes: >> >>> [...] I isolated the cause; the following snippet hangs on Guile 2.2 >>> and 3.0, while it worked as expected on 2.0: >>> >>> ;; -- >>> (import (rnrs)) >>> >>> (let* ((p (pipe)) >>>(in (car p)) >>>(out (transcoded-port (cdr p) (make-transcoder (utf-8-codec) >>> (put-datum out "foo") >>> (flush-output-port out) >>> (display "Should have written to pipe by now, attempting reading a >>> byte\n") >>> (display "Got") >>> (display (get-u8 in)) >>> (newline)) >>> ;; --- >>> >>> It seems the underlying port is no longer flushed to the OS, so the >>> `get-u8` now hangs waiting for input, starting with Guile 2.2. >>> >> I'd like to add that this is indeed not passing data to the OS, as >> verified by strace. Also, I have now figured out the commit introducing >> the regression, namely 8399e7af5 ("Generic port facility provides >> buffering uniformly"); the commit before (e8b1d) still runs the >> above code to completion. > > Actually I think the code above behaves as expected. ‘pipe’ returns > buffered ports by default. When flushing the transcoded port, > ‘transcoded_port_write’ is called, but then bytes written to the pipe > are buffered. > > The fix is to add: > > (setvbuf (cdr p) 'none) > > Does that make sense? > It makes sense, and I can confirm that it makes the boiled-down example I posted work. However, I'm not sure it is the expected behavior. Regardless of buffering modes used, I would expect a `flush-output-port` in a "port stack" (as produced by `transcoded-output-port`) to propagate all the way to the OS. It seems that was the case in Guile 2.0, as I'm pretty sure I observed the "breaking" behavior change with 8399e7af5 applied, and not with the commit preceding it. If the current behavior is indeed the intended one, we should make sure the docs somehow reflect this caveat, as I imagine it may surprise future Guile users which happen to use its R6RS support and pipes in combination. Regards, Rotty
bug#39361: continuation and gc performance
Hi, Stefan Israelsson Tampe skribis: > That function marks the working stack no, what about stack segments in > continuations will they be marked correctly as well? Oh you’re right, from a quick look at continuations.c, a continuation’s stack appears to be conservatively scanned (allocated with ‘scm_gc_malloc’). My intuition is that it’s “good enough” in most cases, but could affect GC performance a tiny bit in continuation-heavy code, such as Fibers. Ludo’.
bug#29001: git patch
Hi Matt, Matt Wette skribis: >>From 71ff7e79369a4514a961fc5cf76593b254c32d4c Mon Sep 17 00:00:00 2001 > From: Matt Wette > Date: Sun, 22 Mar 2020 09:12:37 -0700 > Subject: [PATCH] 2020-03-22 Matt Wette > > * configure.ac: > Provide new option: --disable-tmpnam > This is made available for installations that don't want to allow > the insecure POSIX tmpname function. Use mkstemp! instead. > > * libguile/posix.c > tmpnam is deprecated; and enabled by ENABLE_TMPNAM I tweaked the commit log and pushed. Thank you! Ludo’.
bug#29001: git patch
Attached is the git patch against the following guile commit: bef5e0b3938cc88e3a1a1ac590b009875cc38162 >From 71ff7e79369a4514a961fc5cf76593b254c32d4c Mon Sep 17 00:00:00 2001 From: Matt Wette Date: Sun, 22 Mar 2020 09:12:37 -0700 Subject: [PATCH] 2020-03-22 Matt Wette * configure.ac: Provide new option: --disable-tmpnam This is made available for installations that don't want to allow the insecure POSIX tmpname function. Use mkstemp! instead. * libguile/posix.c tmpnam is deprecated; and enabled by ENABLE_TMPNAM --- configure.ac | 8 libguile/posix.c | 11 +++ 2 files changed, 19 insertions(+) diff --git a/configure.ac b/configure.ac index 6198c7e..3e96094 100644 --- a/configure.ac +++ b/configure.ac @@ -166,6 +166,10 @@ AC_ARG_ENABLE(regex, [ --disable-regex omit regular expression interfaces],, enable_regex=yes) +AC_ARG_ENABLE(tmpnam, + AS_HELP_STRING([--disable-tmpnam],[omit POSIX tmpnam]),, + enable_tmpnam=yes) + AC_ARG_ENABLE([deprecated], AS_HELP_STRING([--disable-deprecated],[omit deprecated features])) @@ -909,6 +913,10 @@ if test "$enable_regex" = yes; then AC_DEFINE([ENABLE_REGEX], 1, [Define when regex support is enabled.]) fi +if test "$enable_tmpnam" = yes; then + AC_DEFINE([ENABLE_TMPNAM], 1, [Define when tmpnam support is enabled.]) +fi + AC_REPLACE_FUNCS([strerror memmove]) # Reasons for testing: diff --git a/libguile/posix.c b/libguile/posix.c index a1520ab..9b9b476 100644 --- a/libguile/posix.c +++ b/libguile/posix.c @@ -87,6 +87,10 @@ #include "vectors.h" #include "version.h" +#if (SCM_ENABLE_DEPRECATED == 1) +#include "deprecation.h" +#endif + #include "posix.h" #if HAVE_SYS_WAIT_H @@ -1588,6 +1592,8 @@ SCM_DEFINE (scm_environ, "environ", 0, 1, 0, } #undef FUNC_NAME +#if (SCM_ENABLE_DEPRECATED == 1) +#ifdef ENABLE_TMPNAM #ifdef L_tmpnam SCM_DEFINE (scm_tmpnam, "tmpnam", 0, 0, 0, @@ -1602,6 +1608,9 @@ SCM_DEFINE (scm_tmpnam, "tmpnam", 0, 0, 0, char name[L_tmpnam]; char *rv; + scm_c_issue_deprecation_warning + ("Use of tmpnam is deprecated. Use mkstemp! instead."); + SCM_SYSCALL (rv = tmpnam (name)); if (rv == NULL) /* not SCM_SYSERROR since errno probably not set. */ @@ -1610,6 +1619,8 @@ SCM_DEFINE (scm_tmpnam, "tmpnam", 0, 0, 0, } #undef FUNC_NAME +#endif +#endif #endif SCM_DEFINE (scm_tmpfile, "tmpfile", 0, 0, 0, -- 2.17.1