On Sun, Oct 07, 2007 at 04:50:36AM +0200, Bruno Haible wrote:
> On mingw, the open(), fopen(), freopen() calls have the problem that they
> do not recognize the filename "/dev/null" under some circumstances.
It's a bug in open that it doesn't recognize a nonexistant device for
a different system?
PS: A third possible implementation - if you want to rely on FLOOR and CEIL -
is like this:
DOUBLE
ROUND (DOUBLE x)
{
if (x >= L_(0.0))
return FLOOR (x + L_(0.5));
else
return CEIL (x - L_(0.5));
}
And another nit:
> +HAVE_DECL_ROUND=0
> +AC_LIBOBJ([round])
> +ROUND_LIBM=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/6/2007 8:50 PM:
>
> The precise circumstances are not clear to me. When I run, from an rxvt
> running the msys /bin/sh,
>
> $ H:/msys/local/bin/msgfmt.exe --statistics /dev/null
>
> it succeeds.
This is because the
Ben Pfaff wrote:
> There is a huge amount of redundancy in the m4 code across all
> six modules (trunc*, round*) and perhaps others. Perhaps I
> should write a common m4 macro that just takes a parameter or two
> and avoids the redundancy. Bruno, do you think that this is a
> good idea?
It may b
The round, roundf, and roundl functions were added in C99 and
hence not supported everywhere. I've written modules for them
that are heavily based on Bruno Haible's modules for trunc,
truncf, and truncl. Here they are. They work OK in my testing.
If I don't receive substantive objections in the
Ben Pfaff noticed that, unlike floor() and ceil(), the function trunc()
is not declared by default on glibc systems. (The difference is in
/usr/include/bits/mathcalls.h.)
This should fix it.
2007-10-06 Bruno Haible <[EMAIL PROTECTED]>
* modules/trunc (Dependencies): Add 'extensions'.
On mingw, the open(), fopen(), freopen() calls have the problem that they
do not recognize the filename "/dev/null" under some circumstances.
This is a problem because there are Cygwin shell scripts (such as configure
files) which pass filenames like /dev/null to programs. The shell calling
such a
Hi Ludovic,
> I'm trying to implement functions that convert a string in the current
> locale encoding to its UTF-{16,32} representation, for a given
> endianness.
This kind of task is outside of the scope of the uniconv/* modules.
'unistr' and 'uniconv' deal wih UTF-{8,16,32} as an internal repr
Hi,
I'm trying to implement functions that convert a string in the current
locale encoding to its UTF-{16,32} representation, for a given
endianness.
`u16-conv-from-enc.c' reads this:
/* Name of UTF-16 encoding with machine dependent endianness and alignment.
*/
#if defined _LIBICONV_VERSI
Jim Meyering wrote:
> Is seq segfaulting on mingw and BeOS, too?
On BeOS, 'seq' is producing junk output (totally out-of-range numbers) but
not segfaulting. As a consequence, the rm/readdir-bug test fails.
On mingw, I don't remember the details, but it was similar.
Bruno
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Martin Koeppe wrote:
>> The Interix libc is built with MSVC. MSVC has no long double data
>> type. Ok, it understands "long double", but always maps that to 64-bit
>> double. So libc's printf(), when it sees "%Lg", expects 64-bit double.
>>
>> But Interix
Martin Koeppe wrote:
> The Interix libc is built with MSVC. MSVC has no long double data
> type. Ok, it understands "long double", but always maps that to 64-bit
> double. So libc's printf(), when it sees "%Lg", expects 64-bit double.
>
> But Interix also has gcc. gcc OTOH has 80 bit long double
12 matches
Mail list logo
