Re: Fwd: Re: error.c: "Unknown system error" should report errno value

[Martin Koeppe]

Hi Jim,

On Wed, 3 Oct 2007, Jim Meyering wrote:

> > > > And yes, I'll of course try a new coreutils/gnulib version (but I
> > > > think in this case I shouldn't yet). Are there any coreutils snapshot
> > > > .tar.gz available?
> > >
> > > Yes.  I made a new snapshot just a few hours ago, too:
> > >
> > >  http://meyering.net/cu/coreutils-6.9-ss.tar.gz
> > >  http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig
> >
> > I now built the newer snapshot from 2-Oct-2007 and ran the tests. Long
>
> Thanks.
> The three that failed with 'Segmentation fault' look like
> good candidates to investigate first.  Can you debug those?

the second and third (they occur when seq is run) are easy to explain, 
but probably difficult to fix...

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 (stored are 
12 bytes). When I build seq with gcc, for the "%Lg" arg 12 bytes are 
reserved. This will crash then.

I don't know how to fix that... Is there a way to force seq to only 
use double, no long double?  OTOH I plan to eventually port glibc 
to Interix some (very?) future day, as I also noticed several other 
problems with Interix's libc.

Are there other long double printf usages in coreutils which might be 
broken on Interix, too?

The first 'Segmentation fault' with dd doesn't occur when I run just 
the failing command in the src dir:
./dd cbs=4 ibs=4 conv=unblock,sync < dd-in > dd-out
dd-out looks fine there. So I don't currently know how to reproduce 
it...

Martin