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: lrint() incorrect results. Date: Mon, 13 Jun 2005 10:39:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: ----Original Message---- >From: Luke Hutchinson >Sent: 04 June 2005 18:27 > Is there any particular reason the same inline functions as defined in the > MinGW header files are not used? They work correctly, and being inlined, > are more efficient. Well, the main reason is that cygwin uses newlib for libc/libm support, and newlib is generic across all CPUs, so it can't use x86-specific inline assembler in quite the same way. However it would be an eminently suitable workaround for your applications. (BTW I've started looking at the code for this. It seems it must never have worked, since these files haven't been modified since they were first added three years ago. I haven't exactly understood the problem yet, but I've figured out that lrintf ought to be just as broken as lrint and only isn't because of a signed-vs-unsigned bug in the code! I have a hunch there may just be a broken endian-ness assumption in the code somewhere, but I'll know more later). 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/