Hi Jim,
> Actually, I see trailing blank lines in any text file
> as an opportunity for unexpected merge conflicts, as
> one person adds or removes one of those oft-unnoticed lines,
> and someone else makes a conflicting change.
Conflicts generally occur at spots that are heavily modified,
such a
Eric Blake wrote:
> On mingw, dup2 always returns 0 for success, rather than the fd just opened.
> So I guess I'll start the process of writing a dup2 replacement module;
Yes, that's definitely a portability pitfall that warrants a wrapper module.
Bruno
Eric Blake byu.net> writes:
> always report ASSERT failures to the original stderr,
> regardless of what the test did to fd 2.
Well, it would work if mingw's dup2 weren't broken. On mingw, dup2 always
returns 0 for success, rather than the fd just opened.
> + /* We might close fd 2 later, so
Bruno Haible wrote:
> Hi Jim,
>
> The git server at savannah now rejects the normal form of module
> descriptions. I got this error message:
>
> modules/pipe-filter:34: ends with blank lines.
> error: hooks/update exited with error code 2
> error: hook declined to update refs/heads/master
>
>
Bruno Haible clisp.org> writes:
> > The verdict - the eucJP (and several other) charset is supported only if
> > you have installed it in your version of Windows (newer versions have it
> > installed automatically). On systems where they are installed, the
> > mbrtowc function works.
>
> Fixing
Eric Blake wrote:
> ... rearranging calls in the parent to avoid deadlock ...
Thanks! This possible deadlock was so easy to overlook.
Bruno
Eric Blake wrote:
> The verdict - the eucJP (and several other) charset is supported only if
> you have installed it in your version of Windows (newer versions have it
> installed automatically). On systems where they are installed, the
> mbrtowc function works.
Fixing setlocale() to return info
>From 640f2ed9570eef3189e43ec7550b32776fdebd0f Mon Sep 17 00:00:00 2001
From: Peter Simons
Date: Sun, 19 Jul 2009 18:25:44 +0200
Subject: [PATCH] lib/sha1.h: wrap declarations in extern "C" scope when
included from C++
---
lib/sha1.h |8
1 files changed, 8 insertions(+), 0 deletion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 7/19/2009 4:53 AM:
> I've committed this. The test now passes on mingw (and of course also on
> Linux and Cygwin).
I'm committing this followup, which fixes a comment rendered stale by your
previous commit, adds the same c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 7/20/2009 5:48 AM:
> According to Bruno Haible on 7/18/2009 10:41 AM:
checking whether mbrtowc has a correct return value... no
>>> This is the first one the Cygwin developers should take care of.
>
> They are looking i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 7/18/2009 10:41 AM:
>>> checking whether mbrtowc has a correct return value... no
>> This is the first one the Cygwin developers should take care of.
They are looking into it.
> The setlocale function [1] installs functio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Right now, wait_subprocess assumes that an exit status of 127 from the
child process implies failure, and prints a message unless null_stderr is
set. However, this led to a regression in m4 1.4.13 - an intentional
status of 127 is ambiguous with failu
[Removed many CCs, changed subject]
Bruce Korb wrote:
> Please have a look at GCC's fixincludes.
> It needs (and uses) a chain of processes.
> See gcc/fixincludes/server.[ch] and ../procopen.c
>
> To solve problems I couldn't figure out, I had to fork() and exit()
> the writer to the chain, or th
13 matches
Mail list logo
