Date: Thu, 16 Mar 2000 17:17:19 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: djgpp-workers AT delorie DOT com Subject: Re: Unnormals??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote: > So the only test that would work to check if a given number is an > unnormal, rather than a signalling NaN would have to operate outside the > FPU, by checking bit patterns directly: > > if (MSB(mantissa)==0) { > if (exponent == max_exponent) > it's a signalling NaN /* nan, to C99 nomenclature */ > else if (exponent == min_exponent) > it's a denormal /* subnormal, to C99 */ > else > it's an unnormal /* undefined in C99 */ > } This is what the internal function `isspeciall' does as part of doprnt.c (the change for unnormals was introduced in preparation for v2.03). > Thus, it's our choice what behaviour signalling NaNs and unnormals > should cause. Not only in printf(), but everywhere. I see two > possibilities, roughly: > > 1) provide a default SIGFPE handler for the 'inavlid operation' excetion > that reads the offending FPU register and 'repairs' it. It would convert a > signalling NaN to a quiet NaN, and an unnormal to a normal (or denormal, > where necessary), respectively. This might be a slow method, but it should > be possible. > > 2) define signalling NaNs and unnormals to belong to class 'nan' of the C > standard. AFAICS, this should fix everything quite nicely. We already kinda took the first alternative: we mask all numerical exceptions at startup. This causes unnormals to produce a NaN, which is then dragged on through the entire computation, usually yielding a NaN in the end. So we don't need to worry about unnormals in the absolute majority of cases. `printf' is special because it must specifically test for the NaN as a bit pattern, to produce the appropriate string required by the standard. Since the existing code tested for the special numbers up front, and then did all the rest under an assumption that the argument is finite, an unnormal would fail it in the way I described. I could, of course, force _doprnt to perform some FP operation on the argument, which would convert it to NaN. However, given the complexity of _doprnt and v2.03 being a bug-fix release, I opted for a safer solution. IMHO, the different string printed helps to spot these cases, which _must_ be bugs. So this solution also has a bonus. > So the current behaviour would also be allowed by the standard. Just let > such programs get what they asked for: a crash of the program by SIGFPE. I'm not sure it's a good idea to enable FP exceptions. They make ANSI compliance in math functions next to impossible, since AFAIK the standard explicitly forbids math functions to crash the program. I think our move to mask all FP exceptions in v2.02 and later was in the right direction.