I strike these errors more in perl than in anything else. (But then, I only ever use perl and C ;-)

Reading the linked bug throws your comment in a bit of a different light:

As to how glibc gets it "right". I pulled apart the glibc and indeed some "clever" person actually tried to take the advice in C99 literally; strtod uses GMP internally to try to get this right. Yes, GMP.

But it still gets it wrong:

[....]

So they just made a string to number conversion not only use MP math and so be very slow, but they didn't even get the "perfect" behaviour they were seeking. "Excessive cleverness"

Practically speaking, Perl's implementation is about as good as you could expect from a high performance solution and as far as I can tell confirms to ieee754 rules. If you want the over-engineered version in glibc, then build your Perl with d_strtod=1

If you want the over-engineered version in glibc, then build your Perl with d_strtod=1

Another way to get glibc to assign the value is to use POSIX::strtod.
Unlike my perl-5.22.0, it correctly assigns '-4.848e1':

C:\>perl -MPOSIX="strtod" -le "print scalar reverse unpack 'h*', pack 
+'d<',strtod('-4.848e1');"
c0483d70a3d70a3d
[download]

In my experience, glibc gets the assignment right for those values that perl gets wrong - though not so much with the non-IEEE "double-double" arrangement, where both are prone to error.
However, I shouldn't assert that perl is any worse at assigning values than glibc. (I don't know how often glibc gets it wrong when perl gets it right.)

Cheers,
Rob