develooper Front page | perl.perl5.porters | Postings from September 2014

Re: new long doubles option: gcc libquadmath

Thread Previous | Thread Next
From:
demerphq
Date:
September 20, 2014 04:05
Subject:
Re: new long doubles option: gcc libquadmath
Message ID:
CANgJU+UyAaR6CXTtLYuaZqVJZ4EPedjmHYW1=07GnZwDR0q_XA@mail.gmail.com
On 20 September 2014 04:25, Josh Juran <jjuran@gmail.com> wrote:

> On Sep 19, 2014, at 1:12 PM, Jarkko Hietaniemi <jhi@iki.fi> wrote:
>
> > I think the "12 bytes" for the x86 extended precision is an "urban
> > legend" of misunderstanding: the number of bits is always 80 (64 for
> mantissa, 15 for exponent, 1 for sign, no "implicit bit").  The 12
> > comes from the ILP32 way of storing the 10-byte thing in three 4-byte
> words.  In LP64 (like x86_64) it's stored in two 8-byte words, hence 16
> > bytes.  The unused bytes (2 or 6) are unused garbage.  They might be
> > zero bits, or they might contain your credit card number.
>
> I know you're being facetious, and crypto uses integer math so we're not
> talking about leaking private key material, but as a general principle,
> transporting garbage should be avoided.  It was bad when Microsoft Word
> bumped a document file's logical EOF to match its physical EOF (thus
> carrying around a partial block of who-knows-what prior data, which very
> well could have included your credit card number), and it's bad now.  Any
> unused bits in the in-memory format should be zeroed before transmission or
> storage.
>

I agree. Sereal will zero the extra bytes. (Cant remember this second if
that is going to be the next release, or the current one.)

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About