Fortran 77 explicitly forbids output of a negative sign for a zero value.

Fortran 90/95 are intended to be compatible with F77 except where noted. The
f90/95 standards omit the statement about not outputting the negative sign for a
zero value.

I preparing a patch to gfortran to print the sign for zero values if the signbit
is set.

My question is: Should gfortran default behavior omit the negative sign and
only show it with a special compiler flag or should the default behavior be to
show the negative sign.?

Example code:

Just my opinion, but I'd recommend that you print the minus sign.
I don't even see a need to have an option to turn it off. It's not
like any old programs could be dependent on the behavior. And
*new* programs might very well depend on getting the sign right.

I the very old days (even before ANSI, the organization was
ASA - the American Standards Association), there was a minor
standard that specified the presentation of printed technical
information (I've got a copy somewhere). For whatever reason,
they decided that if all the displayed digits were zero a negative
sign should not be permitted - even if the value in question was
*not* zero, but the value merely underflowed the decimal
field in which the data was printed. Well, the first Fortran
standard chose that same rule in order to be consistent with
that other standard. It was always a bad idea.

The IEEE floating point standard recommends the opposite.
The display of a value, even if it does compare equal to zero,
should preserve the sign. An F2003 implementation consistent
with IEEE float must do that. So, if you plan to support that
part of F2003, you should keep the sign of zero.

Jerry DeLisle wrote:

One Fortran system that I used in the Fortran 66 days printed a '+'
sign on a negative zero, and only on a negative zero. I don't
remember now why I found that out, but it was pretty surprising
at the time.

That would seem to satisfy even standard that prohibit a '-' sign.

-- glen

James Giles wrote:

The NIST testsuite is, apparently. To which extent that is
representative of real F77 applications, I don't know.

Janne Blomqvist wrote:

Well, given that it's a test suite, it's dependency is probably
that it was deliberately written to test whether zero has a
negative sign printed with it. My guess is that it has no
further meaning than that.

The standard has already changed once. It used to be required
that an output of entirely zero digits must not have a minus sign.
And now (as of F95 I think) if the internal value is negative (other
than negative zero) the output field must have a minus sign - even
if the only digits actually output are zeros. Headway occurs slowly.
I can't find it quickly, but I think F2003 requires the minus sign if
the implementation is IEEE and the internal value is a negative zero.

James Giles wrote:

On Jul 8, 1:14 pm, Jerry DeLisle verizon.net> wrote:

The statement to which I believe you are referring appeared in
FORTRAN 77, was retained in Fortran 90, and was dropped in
Fortran 95. That statement was not present in the FORTRAN 66
standard, but the FORTRAN committee interpreted the language of
that standard as forbidding prefixing the external representation
of a zero value with a minus sign. See interpretation #52 in
"Clarification of FORTRAN Standards - Second Report" by
C. Kerpelman, CACM 14, 10 (October 1971).

robert.corbett@sun.com wrote:

(snip regarding printing of negative zero)

<robert.corbett@sun.com> wrote:

I disagree with the characterization of both the motives and the alleged
contortion.

...

Yes.

glen herrmannsfeldt ugcs.caltech.edu> wrote:

ISO, which is the organization responsible for the standards in
question, has a document that explicitly covers such terms. ISO
Directive 3, if I recall correctly, though I don't feel like dragging it
out to check.

It is quite specific about the use of such terms. "May" indicates
permission. That does have definite meaning in a standard; that's why
ISO lists it. I think that "may not" indicates prohibition, though I'd
have to drag out my copy to be sure.

The possible confusions there are why I prefer "might" instead of "may"
to indicate what could be more elaborately stated as "might or might
not".