Martin Koeppe <[EMAIL PROTECTED]> wrote:
> 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...
How about when y
Martin Koeppe <[EMAIL PROTECTED]> writes:
> 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
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
Paolo Bonzini wrote:
> > - In math.h, do a "#define floorl rpl_floorl", in order to avoid
> > possible undesired compiler optimizations.
>
> No problem, but I wonder what's the rationale for the last item.
It's that I've seen gcc transform some trunc() calls into truncf() calls
or similar.
On 3 Oct 2007, Bruno Haible verbalised:
> Sylvain Beucler wrote:
>> What security issues, by the way? I (re)read the docs but I don't see
>> what it is.
>
> No no, I won't tell anyone how the exploit works :-) But there is an exploit.
There's an even more obvious and trivial DoS attack. (The prob
