Eric,
More details about this one:
> > checking whether mbrtowc has a correct return value... no
>
> This is the first one the Cygwin developers should take care of.
> The test case is in m4/mbrtowc.m4 lines 260..296.
>
> > ../../gltests/test-wcrtomb.c:51: assertion failed
> > ../../gltests/test
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 7/18/2009 10:00 AM:
> Eric Blake wrote:
>> It is due to a bug in gnulib.
>
> Yup. Thanks for committing the test and the fix.
The test is still buggy on mingw; here's a followup for the test to at
least let it compile, an
Eric Blake wrote:
> gnulib-tool could make this part easier by automating it somehow (a new
> command line option to state whether the gnulib.mk fragment will be used
> in the current directory [default], or included from some other directory
> where all relative paths need an extra prefix [as in b
Eric Blake wrote:
> It is due to a bug in gnulib.
Yup. Thanks for committing the test and the fix.
> | if (pipe_stdin)
> |if (pipe (ofd) < 0
> ||| (ofd[1] = fd_safer (ofd[1])) < 0)
>
> This has the effect of setting ofd to {1,5} if exactly one of stdin/stdout
> were
> closed.
Ind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 7/17/2009 6:14 AM:
> According to Akim Demaille on 7/15/2009 6:44 AM:
>> I have tried to write a small test case for gnulib (made to be
>> eventually included there, at least it would be a useful sample). It
>> shows the sam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 7/18/2009 7:50 AM:
> Hi Akim,
>
>> We, at Bison Corp., have some bug occurring on Tru64
>> (http://lists.gnu.org/archive/html/bug-bison/2009-06/msg4.html
>> ) that seems to be related with our piping into GNU M4. Bi
Hi Akim,
> We, at Bison Corp., have some bug occurring on Tru64
> (http://lists.gnu.org/archive/html/bug-bison/2009-06/msg4.html
> ) that seems to be related with our piping into GNU M4. Bison
> basically reads its input, feeds m4 with various files, and "parses"
> the output of m4 befo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 7/18/2009 7:26 AM:
> Eric Blake wrote:
>> How about this patch?
>
> To make it compile on mingw (mingw has neither the fcntl function nor the
> F_GETFL flag), I would change the
>
> #if !_LIBC && defined F_GETFL
Good c
Eric Blake wrote:
> How about this patch?
To make it compile on mingw (mingw has neither the fcntl function nor the
F_GETFL flag), I would change the
#if !_LIBC
to
#if !_LIBC && defined F_GETFL
Bruno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 7/18/2009 6:48 AM:
>> it (although with #if _LIBC guards to make upstream adoption easier).
>>
>> How about this patch? It was enough to fix the behavior of m4 on cygwin
>
> I have a slight preference for omitting the #if
Eric Blake wrote:
> According to Jim Meyering on 7/18/2009 2:42 AM:
>> How about fixing gnulib's lib/error.c to do the right thing?
>> Then if you teach m4/error.m4 to detect when glibc's error function
>> is defective (currently always) it can use the improved replacement.
>
> It is not defective
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 7/18/2009 2:42 AM:
> How about fixing gnulib's lib/error.c to do the right thing?
> Then if you teach m4/error.m4 to detect when glibc's error function
> is defective (currently always) it can use the improved replacement.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 7/18/2009 1:03 AM:
>> calls close_stream (stdout)
>> => fclose (stdout)
>> detects that pending data was lost, so call error()
>> => fflush (stdout)
>>
>> According to POSIX, using stdout after it has been passed to fclose
Rolf Bjarne Kvinge wrote:
> >> Attached are three files (o-file, a-file and b-file) which when run with
> >> git-merge-changelog causes an assertion in:
> >>
> >> #3 0x08049985 in main (argc=Cannot access memory at address 0x34a6) at
> >> git-merge-changelog.c:1469
> >> 1469
Eric Blake wrote:
> But even if cygwin is improved to not trigger an internal fault, and/or
> libsigsegv changed to not interfere with cygwin's detection of internal
> faults,
> it seems that the real root cause is that gnulib has caused the application to
> perform undefined behavior during the a
The bug-gnulib and bug-coreutils mailing lists are now
mirrored (including all archives) also at MARC:
http://marc.info/?l=gnulib-bug
http://marc.info/?l=coreutils-bug
Thanks to Hank Leininger for setting that up,
Jim
Hi Eric,
> I've traced it to the fact that m4 uses the closeout module, which does the
> following:
>
> calls close_stream (stdout)
> => fclose (stdout)
> detects that pending data was lost, so call error()
> => fflush (stdout)
>
> According to POSIX, using stdout after it has been passed to fc
17 matches
Mail list logo
