Eric Blake wrote:
...
> Meanwhile, no one ever reviewed my proposed doc patch:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00167.html
Links to mailman-archived messages are hard to read
the moment they contain a few "@" (address@obfuscated) signs,
so texinfo is much easier to read
On 05/07/2012 01:43 PM, Bruno Haible wrote:
Looks good to me.
Thanks. This seems to be a win regardless of whether it
fixes the nettle problems, so I've pushed it into gnulib
master. We can look into further fixes later as needed.
Paul Eggert wrote:
> + stdint: be more consistent with glibc, SunOS libc
> + * lib/stdint.in.h (gl_int_fast8_t, gl_uint_fast8_t)
> + (gl_int_fast16_t, gl_uint_fast16_t)
> + (gl_int_fast32_t, gl_uint_fast32_t)
> + (INT_FAST8_MIN, INT_FAST8_MAX, UINT_FAST8_MAX)
> + (INT_FAST16
On 05/07/2012 10:13 AM, Niels Möller wrote:
> I thought the point of gnulib was to do those annoying things to keep
> the maintanance in one place.
True. Very true.
OK, how about the following patch to gnulib's lib/stdint.in.h?
Does it fix the problem?
And if not, could you please explain what
Hi Eric,
Thank you for digging out the previous threads on this topic.
Eric Blake wrote:
> Wy back when, coreutils used to use SET_BINARY. We changed that to
> use freopen(NULL) because of the POSIX wording that allowed NULL to
> change mode, because cygwin honored the mode change, and becau
On 05/01/2012 11:19 PM, Akim Demaille wrote:
> Hi Eric,
>
> Sorry for the delays,
No problem.
>
> Le 25 avr. 2012 à 19:36, Eric Blake a écrit :
>
>> On 04/07/2012 05:48 AM, Akim Demaille wrote:
>>> Hi!
>>>
>>> I would like bison to used gnulib's build-aux/po/Makefile.in.in,
>>> but I don't und
[adding coreutils]
On 05/07/2012 12:11 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> POSIX says that such a call is implementation-defined, so technically,
>> mingw DOES implement the POSIX semantics (by defining that it is
>> unsupported).
>
> Yes. So, code in freopen.c that would try to suppor
On 02/24/2012 08:52 AM, Eric Blake wrote:
> Right now, isatty is LGPLv3+; but libvirt would like to use it and would
> require it to be LGPLv2+. Any objection to relaxing the license?
>
> Bruno and Marc-André are the only authors to lib/isatty.c, and all other
> module dependencies are already LG
Eric Blake wrote:
> POSIX says that such a call is implementation-defined, so technically,
> mingw DOES implement the POSIX semantics (by defining that it is
> unsupported).
Yes. So, code in freopen.c that would try to support a NULL argument
in all cases
- would be a gnulib extension,
- would
> Date: Mon, 07 May 2012 06:44:00 -0600
> From: Eric Blake
> CC: bug-gnulib@gnu.org, bug-gnu-ut...@gnu.org
>
> > FILE *
> > rpl_freopen (const char *filename, const char *mode, FILE *stream)
> > {
> > #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> > - if (filename != NUL
Paul Eggert writes:
> Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not
> mention int_fast*_t, except in stdint.h where C requires their definition.
I'd consider that definition to be authoritative...
> Presumably this is for the same reason that Gnulib avoids these ty
On 05/05/2012 05:18 AM, Eli Zaretskii wrote:
> Diffutils 3.2 call xfreopen with its first argument NULL, expecting
> the underlying reopen to handle this. However, the MS runtime does
> not implement the Posix semantics of such a call,
POSIX says that such a call is implementation-defined, so tec
12 matches
Mail list logo
