[Bug libfortran/47567] Wrong output for small absolute values with F editing

["thenlich at users dot sourceforge.net" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567

--- Comment #12 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-02-07 07:01:14 UTC ---
(In reply to comment #11)
> Fixed on trunk.  I don't think this is significant enough to justify a
> back-port. I am not sure why anyone would use f1.X for anything, so this
> exercise is largely academic. I do appreciate the bug reports. Thanks

Thank you for your work on this and for the fast response, which is actually
better than what you get from the "premier" support of some big commercial
compiler vendors.

Of course I agree with you that noone would use (F1.n) editing, that was
exactly my point, see my comment #1: "Any formatting ... with (F1.n) should
always result in asterisks".

However, because of the rule for (F0.n) we need to make clear what is "the
smallest positive actual field width that does not result in a field filled
with asterisks".

print "(F0.0)", 0.0   ! => 0

I'm still pretty sure that this is not compliant to Fortran 2003/2008 and I
would like a convincing explanation why it should be. Of course I can
understand the argument that "0" instead of "0." is useful to express the "real
zero", but I think standard-compliance takes precedence, making it easier for
the user to write portable programs.

In my interpretation, the demand of "a string of digits that contains a decimal
symbol" is equivalent to the syntax:

DIGIT ... DECIMAL-SYMBOL [DIGIT] ...
|
[DIGIT] ... DECIMAL-SYMBOL DIGIT ...

The clause "The optional zero shall appear if there would otherwise be no
digits in the output field." rules out the string becoming just:

DECIMAL-SYMBOL

As I see it, the decimal symbol is not optional and cannot be left out, so the
output "0" is illegal.

The phrase "contains" means that e.g. the Java method
string.contains(decimal_symbol) would return true.