Thanks for writing all that. One comment about the list containing this item:
+@item
+If your program opens only one new file descriptor or FILE stream at a time,
+it is @emph{not affected}.
Isn't the problem more general than what this list suggests? Considering the
list item quoted above, eve
Thanks for the xstdopen module; it simplifies diffutils and I installed the
attached patches there for it.
>From 86ece0ee216910bce0dbceb60b98190bf8f93702 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 6 Jan 2019 17:15:06 -0800
Subject: [PATCH 1/2] build: update gnulib submodule to latest
Bruno Haible wrote:
That build failure occurred even with the Gnulib module 'c99' included.
When this topic came up in 2017, you asked whether we should bury support for
IRIX cc[1], I opined that we should drop support[2], and Tom G. Christensen said
you needed MIPSpro 7.4.0 or later for c99
Eric Blake wrote:
> I've now applied the patches, with tweaks as discussed on 1/2.
In GNU gettext, I now see this message when using the top-level GNUmakefile:
/bin/bash: rsyncable: command not found
The reason is that GNU gettext imports the relevant files directly (via
'gnulib-tool --copy-file
The last platform which lacked setlocale() was probably SunOS 4.
2019-01-06 Bruno Haible
localename: Assume setlocale function.
* lib/localename.c (gl_locale_name_posix): Assume setlocale exists.
* m4/localename.m4 (gl_LOCALENAME): Don't test whether setlocale exists.
Here I'm adding basic documentation for the five generic container data types.
2019-01-06 Bruno Haible
doc: Add documentation about container data types.
* doc/containers.texi: New file.
* doc/gnulib.texi (Particular Modules): Include it.
diff --git a/doc/containers.t
The documentation section "error and progname" is not up-to-date any more,
since 'error' was changed to use 'getprogname()' on 2016-09-05. This patch
fixes it.
2019-01-06 Bruno Haible
doc: Update documentation about 'progname' module.
* doc/progname.texi: Rename from doc/error
I wrote:
> I would like to use this modules in GNU gettext and GNU libiconv.
Well, I thought that most programs do need one form of the mitigation
against the closed file descriptors. I'm surprised to see not the case
for any of the programs from GNU gettext and GNU libiconv.
This deserves some d
On Sunday, January 6, 2019 3:22:01 AM CET Andrew Pennebaker wrote:
> Ach, I've made a career out of not having to know autotools! ./configure &&
> make && [sudo] make install were black boxes as far as I was concerned.
>
> So be it, I'll spend some time reading up this weekend and see how far I
>
PS:
> 1) A compilation failure with IRIX cc:
That build failure occurred even with the Gnulib module 'c99' included.
Bruno
Paul Eggert wrote:
> I resurrected and refreshed that old Coreutils code and put it into a new
> Gnulib
> module stdopen
I would like to use this modules in GNU gettext and GNU libiconv. But I'm
encountering two issues:
1) A compilation failure with IRIX cc:
cc -n32 -DHAVE_CONFIG_H -I. -I../..
11 matches
Mail list logo
