Re: vasnprintf fix

Eric Blake wrote: > I have fixed some memory handling bugs that were in newlib at the time > cygwin 1.5.24 was released. They were probably due to the BSD heritage of some parts of newlib? Another question is how to deal with the bug on MacOS X ? This is a widely used platform, and there are seve

Re: vasnprintf fix

Bruno Haible clisp.org> writes: > Now that you say it, it's obvious what is going on: the code has first > decided that it doesn't need the 'a'/'A' substitute (since Cygwin already > has it) and then decided that it needs to emulate 'A'/'A' (because Cygwin > either crashes in low-memory situation

Re: vasnprintf fix

Hello Eric, > Something's still fishy. Now I'm getting aborts for test-vasprintf-posix.c > on > cygwin, with the following sequence of instructions in vasnprintf.c: > > Breakpoint 1, test_function (my_asprintf=0x413052 ) > at ../../tests/test-vasprintf-posix.c:173 > 173 int retval =

Re: realloc.c on Tru64 4.0D

Jim Meyering wrote: > >> 2007-10-27 Ralf Wildenhues <[EMAIL PROTECTED]> > >> Bruno Haible <[EMAIL PROTECTED]> > >> > >>* modules/malloc (configure.ac): Define GNULIB_MALLOC_GNU always. > >>* modules/realloc (configure.ac): Define GNULIB_REALLOC_GNU always. > >>* lib/reall

Re: vasnprintf fix

Eric Blake byu.net> writes: > Something's still fishy. Now I'm getting aborts for test-vasprintf-posix.c on > cygwin git bisect narrowed it down to this commit: 7cd87873c8336cb43c0452df4b11238f014be8a1 is first bad commit commit 7cd87873c8336cb43c0452df4b11238f014be8a1 Author: Bruno Haible <

Re: vasnprintf fix

Bruno Haible clisp.org> writes: > > The floating-point output code crashed due to an abort() for values with > large exponents (> 1e34 for 'double'). This fixes it. > > 2007-11-04 Bruno Haible clisp.org> > > * lib/vasnprintf.c (scale10_round_decimal_decoded): Fix shift loop. Somethin

Re: uh oh: when to use the xprintf module

On Sat, Nov 03, 2007 at 12:23:16AM +0100, Jim Meyering wrote: > This is not totally fair, because while I made mmap64 return -1, > I did not set errno, which would normally happen for a real failure. > I tried, but __errno_location() returns an invalid address. FYI, try ((int * (*) ()) __errno_loc

Re: realloc.c on Tru64 4.0D

Bruno Haible <[EMAIL PROTECTED]> wrote: > In > I proposed a fix, jointly with Ralf, for the realloc.c problem that Ralf > reported. Comments about it? (It's your territory.) > >> 2007-10-27 Ralf Wildenhues <[EMAIL PROTECTED]> >>

Re: realloc.c on Tru64 4.0D

Hi Jim, In I proposed a fix, jointly with Ralf, for the realloc.c problem that Ralf reported. Comments about it? (It's your territory.) > 2007-10-27 Ralf Wildenhues <[EMAIL PROTECTED]> > Bruno Haible <[EMAIL PROTE

Re: isnanl returns true for 2 and 3 on x86 openbsd 3.9

Hi Jim, > openbsd$ ./seq 4 > 1 > nan > nan > 4 Must be specific to OpenBSD/x86. I don't reproduce it on NetBSD 3.0/x86. > I tracked this to printf-posix's use of isnanl. Yes, that's quite obviously the isnanl-nolibm module (or the system's isnanl() function or isnan() macro). > That