Re: [PATCH] binary-io: do not treat set_binary_mode() on stdin/out/err as an error on OS/2

Bruno Haible wrote: > KO Myung-Hun wrote: >> setmode(O_BINARY) on tty works well instead >> of returning -1 as previous set_binary_mode() does. > > "works well", but isn't this the case which produces staircase-shaped > output? > setmode(O_BINARY) on tty causes the staircase-shaped output. An

Re: getgroups.c failes to compile

Mohammad Akhlaghi wrote: > > How can I get the `-L' part of `LTLIB' into LDFLAGS? > > The problem is fixed now. As suggested in the documentation, I just > appended the necessary `LIB' entries to `LDADD' and included > `LDADD' to the `program_LDADD' (of `Makefile.am'). Additionally: Automake of

Re: AC_LIB_HAVE_LINKFLAGS: linking with static library on macOS

Mohammad Akhlaghi wrote: > In Gnuastro, we recently changed to using `AC_LIB_HAVE_LINKFLAGS' for > all our library dependencies at configure time. > > But while testing it on a macOS machine yesterday we came up with the > following problem: > > The machine only has a static version of one of t

Re: Why does close_stdout close stdout and stderr?

Bruno Haible wrote: For the other case, we can introduce, next to the !SANITIZE_ADDRESS test, tests for getenv ("LD_PRELOAD") != NULL getenv ("ASAN_OPTIONS") != NULL getenv ("TSAN_OPTIONS") != NULL getenv ("MSAN_OPTIONS") != NULL getenv ("LSAN_OPTIONS") != NULL We can add more such

Re: [PATCH] binary-io: do not treat set_binary_mode() on stdin/out/err as an error on OS/2

Bruno Haible wrote: So you have a problem with the patches by Paul in and then in coreutils https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff

Re: [PATCH] binary-io: do not treat set_binary_mode() on stdin/out/err as an error on OS/2

KO Myung-Hun wrote: > setmode(O_BINARY) on tty works well instead > of returning -1 as previous set_binary_mode() does. "works well", but isn't this the case which produces staircase-shaped output? > In addition, set_binary_mode() breaks the compatibility with > SET_BINARY() before set_binary_mod

Re: [PATCH] binary-io: do not treat set_binary_mode() on stdin/out/err as an error on OS/2

Hi/2. Bruno Haible wrote: > KO Myung-Hun wrote: >> * lib/binary-io.c (__gl_setmode_check) [__EMX__]: Remove __EMX__ guard. >> * lib/binary-io.h (__gl_setmode_check) [__EMX__]: Remove __EMX__ guard. >> (set_binary_mode) [__EMX__]: Override mode with O_TEXT if tty. > > According to the EMX document

Re: [PATCH] binary-io: do not treat set_binary_mode() on stdin/out/err as an error on OS/2

KO Myung-Hun wrote: > * lib/binary-io.c (__gl_setmode_check) [__EMX__]: Remove __EMX__ guard. > * lib/binary-io.h (__gl_setmode_check) [__EMX__]: Remove __EMX__ guard. > (set_binary_mode) [__EMX__]: Override mode with O_TEXT if tty. According to the EMX documentation of the setmode function --

Re: [PATCH] flexmember: update comment

Hi Paul, > I gave that a shot by installing the attached. Thanks. I found the relevant references now, in [1]. The fact that some people see it not as a property of the malloc() function but as a GCC bug [2] indicates that it should also apply when alloca() is used to allocate the memory. (In

Re: Why does close_stdout close stdout and stderr?

Florian Weimer wrote in : > The relevant case is where there is no error, and we do not call _exit. > I'm worried that the current implementation introduces a use-after-free > bug under certain, quite reasonable circumstances. Al

Re: Why does close_stdout close stdout and stderr?

Paul Eggert wrote: > A better fix ... would be to write a better module (we could call it > "flushout", say) that would define a function ("flushout_stream", say) > that would act like fflush but would do a better job with NFS-based > streams by playing the dup+close+fsync trick. We could then m

Re: argmatch: accept perfect matches in documented arglists

Hi all, Here is my proposal. Compared to the previous one: - I have declared all the public API functions external. If you have an opinion about what's to be done (e.g., passing an additional argument to ARGMATCH_DEFINE_GROUP), let me know. I'd prefer to do that in another commit though.