On 02/04/2012 10:59 AM, Eric Blake wrote:
> On 02/04/2012 09:56 AM, Eric Blake wrote:
>> On Cygwin, and other platforms where // is detected as distinct
>> from / at configure time, the canonicalize routines were incorrectly
>> treating all instances of multiple leading slashes as //.
>> See also c
On mingw, I'm seeing this test failure:
test-ptsname_r.c:117: assertion failed
FAIL: test-ptsname_r.exe
The reason is that our ptsname_r implementation assumes that isatty()
sets errno when it returns 0, but our isatty() replacement does not do this.
This fixes it (at least for mingw):
2012
On 02/04/2012 09:56 AM, Eric Blake wrote:
> On Cygwin, and other platforms where // is detected as distinct
> from / at configure time, the canonicalize routines were incorrectly
> treating all instances of multiple leading slashes as //.
> See also coreutils bug http://debbugs.gnu.org/10472
>
> *
On mingw, this error message was seen:
test-nonblocking-reader.h:110: assertion failed
(NULL): ./test-nonblocking-socket-child.exe subprocess got fatal signal 15
test-nonblocking-socket-main.c:117: assertion failed
FAIL: test-nonblocking-socket.sh
Obviously, the variable program_name had the valu
Eric Blake wrote:
> canonicalize-lgpl had the same bug
Please, feel free to fix it there as well.
Bruno
On 02/04/2012 09:56 AM, Eric Blake wrote:
> On Cygwin, and other platforms where // is detected as distinct
> from / at configure time, the canonicalize routines were incorrectly
> treating all instances of multiple leading slashes as //.
> See also coreutils bug http://debbugs.gnu.org/10472
>
> *
On Cygwin, and other platforms where // is detected as distinct
from / at configure time, the canonicalize routines were incorrectly
treating all instances of multiple leading slashes as //.
See also coreutils bug http://debbugs.gnu.org/10472
* lib/canonicalize.c (canonicalize_filename_mode): Don'
On native Windows platforms, there is this failure:
test-ioctl.c:38: assertion failed
FAIL: test-ioctl.exe
This patch fixes it.
2012-02-04 Bruno Haible
ioctl: Fix test failure on native Windows.
* lib/ioctl.c: Include msvc-nothrow.h.
(primary_ioctl): If fd is not
> Wrong place for the fix. POSIX requires that inclusion of
> exposes size_t. Therefore, the real fix is to make the gnulib
> replacement header stdio.in.h pull in to define size_t when
> building for SunOS4; at which point every single other file that relies
> on the POSIX requirement, like ha
On all native Windows platforms, we have this test failure:
test-fsync.c:73: assertion failed
FAIL: test-fsync.exe
This fixes it.
2012-02-04 Bruno Haible
fsync: Avoid test failure on native Windows.
* lib/fsync.c (fsync) [Windows]: Don't fail if the handle is merely
On 02/04/2012 06:44 AM, Michael Haardt wrote:
>>> I am afraid that being active maintainer asks for more time than I have
>>
>> That's quite understandable. I used SunOS 4 heavily, but
>> it's now just a museum piece, and it doesn't appear to be
>> worth your time or ours to maintain GNU utilities
> the problem with a gnulib testdir for the modules
>
> unistd stdlib pthread signal sys_select allocator mkstemp pthread_sigmask
> ...
> 2012-02-04 Bruno Haible
>
> sys_select: Avoid syntax error on OpenBSD 5.0.
> * lib/sys_select.in.h: Include only after the include_next
>
Jiri B wrote:
> any news?
>
> I sent requested file
>
> http://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00258.html
Thanks for the reminder. The allocator.i file reveals that the fd_set
type is being used in /usr/include/unistd.h:255 but it is only defined
later, in /usr/include/sys/selec
> > I am afraid that being active maintainer asks for more time than I have
>
> That's quite understandable. I used SunOS 4 heavily, but
> it's now just a museum piece, and it doesn't appear to be
> worth your time or ours to maintain GNU utilities on it.
> (If the best way to run an environment i
Bruno Haible wrote:
> Hi Jim,
>
>> setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
>> getrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
>
> No brk() calls. It looks really like GCC has optimized out the two malloc()
> calls. And indeed, with a re
Hi Jim,
> setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
> getrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
No brk() calls. It looks really like GCC has optimized out the two malloc()
calls. And indeed, with a recent GCC 4.7 snapshot I reprodu
Bruno Haible wrote:
> Hi Jim,
>
>> That test fails on Fedora 16 and I didn't have time to investigate.
>> Here are details, and I'm Cc'ing bug-gnulib:
>>
>> $ ./test-get-rusage-as
>> ../../gltests/test-get-rusage-as.c:56: assertion failed
>> zsh: abort (core dumped) ./test-get-rusage-
17 matches
Mail list logo
