From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3B0EB7C6-3BC1-11D8-906F-000A95C53D8A@suspicious.org> Content-Transfer-Encoding: 7bit From: suspect@suspicious.org Subject: Re: [9fans] libfmt/libutf and long double To: 9fans@cse.psu.edu Date: Wed, 31 Dec 2003 13:43:31 -0500 Topicbox-Message-UUID: b0d0a540-eacc-11e9-9e20-41e7f4b1d025 Hello, Actually, my curiosity was about why it worked on my Plan 9 machine but gave the strange behavior when using libfmt on a UNIX system. From http://www.cs.bell-labs.com/magic/man2html/2/fprintf: "... or an optional L specifying that a following e, E, f, g, or G conversion specifier applies to a long double argument." The above made it make sense to me that it worked on my Plan 9 machine. I'm therefore a bit confused by your response. Thanks. cheers, On Dec 31, 2003, at 11:17 AM, Russ Cox wrote: > > yes, plan 9 doesn't implement long double and your unix does. > >> Hello, >> >> I've run into a behavior with libfmt/libutf on UNIX system >> that does not seem intuitive: >> >> long double ldv = 3.3; >> print("long double var = %llE\n", ldv); >> >> gives: >> long double var = -6.257775E+92 >> >> Identical code under Plan 9 gives the expected output of: >> >> long double var = 3.300000E+00 >> >> Is there any particular reason why the behaviors should >> differ in this manner ?