This ports some stdio primitives to uClibc. With this, the tests pass
in a non-cross i686-linux-uclibc build.
2007-06-08 Bruno Haible <[EMAIL PROTECTED]>
Port to uClibc.
* lib/fbufmode.c (fbufmode): Add special code for uClibc.
* lib/fpurge.c (fpurge): Likewise.
Hi all,
uClibc has another printf bug, not encountered on other systems:
sprintf ("%f", 1.234321234321234e15);
should return "1234321234321234.00"
(because we know that the value is an integer, and there are no rounding
errors in the decimal to binary conversion),
but returns "123432123432
On 6/8/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-08 11:54:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> On 6/8/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> > hexdump (&my_long_double, sizeof my_long_double());
> > kill (getpid (), SIGABRT);
>
> or just call ab
James Youngman wrote:
On 6/8/07, Nix <[EMAIL PROTECTED]> wrote:
I'd say this behaviour violates the principle of least astonishment, at
least. Mind you, avoiding it does seem like it could be expensive: [...]
Maybe. For the issue-diagnostic-message use case, performance is not
such an issue
On 8 Jun 2007, Jeremy Linton verbalised:
> James Youngman wrote:
>> On 6/8/07, Nix <[EMAIL PROTECTED]> wrote:
>
>>> I'd say this behaviour violates the principle of least astonishment, at
>>> least. Mind you, avoiding it does seem like it could be expensive: [...]
>> Maybe. For the issue-diagnost
Petr Baudis wrote:
On Thu, Jun 07, 2007 at 05:02:53PM CEST, Jeremy Linton wrote:
From monitoring this mailing list for a while it appears apparent
that certain people pride themselves in rejecting any patch which improves
the robustness of glibc.
I would describe it rather as not trading per
On 8 Jun 2007, James Youngman said:
> On 6/8/07, Nix <[EMAIL PROTECTED]> wrote:
>> I'd say this behaviour violates the principle of least astonishment, at
>> least. Mind you, avoiding it does seem like it could be expensive: [...]
>
> Maybe. For the issue-diagnostic-message use case, performance i
On Thu, Jun 07, 2007 at 05:02:53PM CEST, Jeremy Linton wrote:
> From monitoring this mailing list for a while it appears apparent
> that certain people pride themselves in rejecting any patch which improves
> the robustness of glibc.
I would describe it rather as not trading performance fo
On Fri, 2007-06-08 11:54:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> On 6/8/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> > hexdump (&my_long_double, sizeof my_long_double());
> > kill (getpid (), SIGABRT);
>
> or just call abort() which is designed for the purpose.
>
> > That way,
On 6/8/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
In this setup, you control all the cluster and you can ensure that all
nodes use the same hardware and that no node will send data over the
network that wasn't the result of CPU calculation.
In the ticket, the case was different in that he
Jim Meyering wrote:
> Well, at least it is not IA64-specific.
> To trigger it you need a "long double" type longer than 8 bytes.
More precisely, it occurs for floating-point data formats in which the
most significant mantissa bit is not "hidden".
- It does not occur with IEEE 754 'float', 'doubl
On Fri, 2007-06-08 10:48:02 +0200, Jim Meyering <[EMAIL PROTECTED]> wrote:
> This started with Bruno Haible's bug report:
>
> > printf crashes on some 'long double' values
> > http://sourceware.org/bugzilla/show_bug.cgi?id=4586
>
> I objected to the closure of that BZ:
>
> http://thr
On Fri, 2007-06-08 09:53:24 +0100, James Youngman <[EMAIL PROTECTED]> wrote:
> On 6/8/07, Nix <[EMAIL PROTECTED]> wrote:
> > It's somewhat unusual for applications to accept double-format data over
> > the network or from files; but modulo byte-swapping, has anyone *ever*
> > seen an application th
On 6/8/07, Nix <[EMAIL PROTECTED]> wrote:
It's somewhat unusual for applications to accept double-format data over
the network or from files; but modulo byte-swapping, has anyone *ever*
seen an application that checks to be sure that the data it's received
is a valid IEEE754 floating-point numbe
This started with Bruno Haible's bug report:
> printf crashes on some 'long double' values
> http://sourceware.org/bugzilla/show_bug.cgi?id=4586
I objected to the closure of that BZ:
http://thread.gmane.org/gmane.comp.lib.glibc.alpha/12394
because I don't want to have to use bulky *
On Thu, 2007-06-07 10:02:53 -0500, Jeremy Linton <[EMAIL PROTECTED]> wrote:
> From monitoring this mailing list for a while it appears apparent
> that certain people pride themselves in rejecting any patch which
> improves
> the robustness of glibc.
Is "robustness" like "not crashin
On 8 Jun 2007, Jan-Benedict Glaw stated:
> On Fri, 2007-06-08 00:14:34 +0100, Nix <[EMAIL PROTECTED]> wrote:
>> It's somewhat unusual for applications to accept double-format data over
>> the network or from files; but modulo byte-swapping, has anyone *ever*
>> seen an application that checks to be
17 matches
Mail list logo
