Re: One-liner breaks "strtold" in XCode 2.4
Re: One-liner breaks "strtold" in XCode 2.4
- Subject: Re: One-liner breaks "strtold" in XCode 2.4
- From: Terry Simons <email@hidden>
- Date: Tue, 28 Nov 2006 20:03:30 -0700
For what it's worth, I'm seeing this too with your code example on my
MacBook Pro...
SlackBookPro:~ terry$ uname -a
Darwin SlackBookPro.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep
25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
SlackBookPro:~ terry$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5363)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
SlackBookPro:~ terry$ uname -a
Darwin SlackBookPro.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep
25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
SlackBookPro:~ terry$ gcc -o bug2 bug2.c
SlackBookPro:~ terry$ ./bug2
nan
On Nov 28, 2006, at 7:18 PM, Jay Reynolds Freeman wrote:
My code establishes that a numeric string which manifestly is
not a nan is interpreted as a nan by "strtold". I am running
on a Macbook 1,1 with OS 10.4.8. The version of gcc is that
which came with the download of XCode 2.4.1, which is gcc-4.0;
however, I believe the problem is in a library which is not
part of gcc per se. I think the library is provided by Apple.
I have done a google search for information about this bug,
and turned up some possible reports that the bug may be related
to the fact that "long doubles" are in IEEE 80-bit format on
the Macbook. Reports indicate that in architectures using
IEEE 64-bit format for long double, the problem does not
occur. Thus if you try to duplicate my bug, your mileage
may vary depending on what processor you are using.
In particular, if your compiler reports that
sizeof( long double ) is 8 bytes, you may not see the bug.
(IEEE 80-bits take at least 10 bytes, and maybe more if
data must be word-aligned.)
Non-zero bits in the output are common when the floating-point
representation in use cannot represent the input string
with perfect accuracy. That's not what is going on
here. What I get is: (cut-and-paste of terminal output)
> gcc -o bug2 bug2.c
> bug2
nan
-- Jay Reynolds Freeman
---------------------
email@hidden
http://web.mac.com/jay_reynolds_freeman (personal web site)
On Nov 28, 2006, at 5:31 PM, Justin C. Walker wrote:
On Nov 28, 2006, at 14:37 , Jay Reynolds Freeman wrote:
I have a one-line C program that breaks "strtold"
(string to long double) when compiled with gcc and
linked with the libraries that came with XCode 2.4,
running on a Macbook with OS X 10.4.8.
You don't say what "breaks" means. You also don't say what
version of gcc you are using.
I would be curious myself to know whose problem
this is, so that I can report it appropriately
if it is not Apple's
If this posting is inappropriate here, please
forgive me, I just joined the group.
This is a reasonable place to discuss this; so is the 'unix-
porting' list. The Xcode list is more for issues dealing with the
IDE itself.
FWIW, I find that your code produces reasonable results with gcc
4.0.1. With 3.3 (on 10.4.8 and 10.3.9) and 3.1 (on 10.3.9), I get
a bunch of non-zero bits in the output where there should
presumably be 0's.
Justin
--
Justin C. Walker, Curmudgeon-at-Large
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden