Date: Wed, 20 Jan 1999 13:13:21 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: djgpp-workers AT delorie DOT com Subject: Re: Bug when printing long doubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com On Wed, 20 Jan 1999, Hans-Bernhard Broeker wrote: > It should print the actual value. After all, even an unnormalized fp > number does have a value. I thought about such a possibility (it seems that Linux, at least in some versions, does that), but decided I don't like it. The reason is that if you print it as a normal FP number, how does John Doe the programmer, who has his program crash or produce NaNs, will ever be able to guess that this number is the culprit? E.g., imagine that `sprintf' is used by a debugger to display such numbers (which is the context where Robert discovered this problem in the first place), or even simple printf debugging. > Of course, it my turn out to be quite tricky to get this done > right (we'ld have to normalize the number ourselves, by multiplying it by, > say, 1e100, and then keep in mind to modify the exponent of the printed > number accordingly). You can't multiply this number by anything: if you do, you get a NaN as a result. This is exactly the reason that I don't think printing it as a normal number is a good idea: how could anybody guess why a perfectly valid number yields a NaN when multiplied by another valid number? So making this happen requires to fiddle with bits, any FP instruction is a no-no. Of course, shifting bits isn't exactly rocket science, either... > On a side issue: as per the C9x standard, it seems we'll have to change > from 'NaN' and 'Inf' to 'nan' and 'inf' at some point in time. Does C9X indeed diverge from existing art so much? Do they disallow Inf and NaN?