Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Subject: RE: SV: Bug in printf ? Date: Wed, 6 Jul 2005 10:29:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: ----Original Message---- >From: Lev Bishop >Sent: 06 July 2005 09:15 > On 06/07/05, Lev Bishop wrote: >> 4) I have no idea what mingw is doing, but it's different to the >> above. Gcc constructs the same double precision constants as on cygwin >> but strtod() is different and seems to have less precision, and >> printf() seems to work with about 16 digits precision. At a glance I'd >> say it rounds to zero, with exactly the precision of > ... the precision of a raw double. > > Ie, it looks like the cygwin build works slightly nicer than mingw > with plenty of extra precision for conversions to and from decimal, > and round-to-even for runtime conversions, which is a good thing. Thanks a great deal for looking at this; I'm not any kind of an FP expert, I just have a grasp of the basics. I've tried the testcase on an RH system and yes, glibc and newlib agree here. What mingw does is simple: it calls M$'s implementation in the msvcrt library, so blame the beast of redmond for the technically-incorrect-yet-reasonable-seeming behaviour. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/