Space padding in DATE_AND_TIME
Clive Page
each tends to find bugs the other doesn't. I just tripped up on
something they do differently, which this trivial code fragment
illustrates
CHARACTER(LEN=12) :: date, time
CALL DATE_AND_TIME(date, time)
Using g95 the variables are both returned with spaces filling the unused
character positions; with gfortran the unused positions are filled with
junk (probably whatever was in there already). TRIM() when writing them
obviously doesn't help. Naturally I can reduce these variables to the
right length for the job, but I thought that space-padding was required
here, as it is when using say the INQUIRE statement. Now I'm not so
sure.
In Fortran90 Standard: section 13.13.16 for the DATE argument says that
the argument length must have a length of at least 8 and the leftmost 8
characters are set to the date string. It is clear that calling it with
a longer argument is legal, but it doesn't say whether the remaining
character positions should be returned having been set to spaces (blanks
in Standardese). The Fortran95 Standard seems to be essentially the
same.
I can't see anything else in Fortran90/95 that is relevant here, but in
the Fortran2003 Standard the last sentence of 13.2 says:
"Intrinsic subroutines that assign values to arguments of type character
do so in accordance with the rules of intrinsic assignment (7.4.1.3)".
That section (not surprisingly) specifies that spaces are appended in an
assignment where the string on the left (== actual arg) is longer.
So my interpretation is that a Fortran2003 compiler ought to pad DATE
and TIME with spaces, but perhaps a Fortan90/95 one need not. Can
anyone else find better authority than this? Maybe I should report this
to the gfortran developers as something like a bug.
--
Clive Page
Tobias Burnus
> CHARACTER(LEN=12) :: date, time
> CALL DATE_AND_TIME(date, time)
>
> Using g95 the variables are both returned with spaces filling the unused
> character positions; with gfortran the unused positions are filled with
> junk (probably whatever was in there already).
If you fill the string with data before calling DATE_AND_TIME, you see
that gfortran (NAG f95 v95 and ifort 11.0) only touch the the first
characters while g95 (openf95 and pathf95) pad the output.
> In Fortran90 Standard: section 13.13.16 for the DATE argument says that
> the argument length must have a length of at least 8 and the leftmost 8
> characters are set to the date string. It is clear that calling it with
> a longer argument is legal, but it doesn't say whether the remaining
> character positions should be returned having been set to spaces (blanks
> in Standardese). The Fortran95 Standard seems to be essentially the same.
I read the standard such that the processor (compiler) should only set
the first characters and that padding is not supposed to happen:
F95, 13.14.27: "DATE [...] Its leftmost 8 characters are assigned a
value of the form CCYYMMDD [...] If there is no date available, they are
assigned blanks."
This restriction is gone in Fortran 2003 and 2008 and, thus, I agree
that padding should happen in Fortran 2003/2008. From the standard:
F2008, 13.7.44: "DATE [...] It is assigned a value of the form
CCYYMMDD, [...] If there is no date available, DATE is assigned all blanks."
This seems to be one of the incompatible changes between Fortran 95 and
2003. Contrary to the "-0" where some programs depend on the positive
zero (and compilers thus have options such as -fno-sign-zero or -assume
nominus0), switching to the F2003 version without a new flag does not
seem to cause problems for (nearly?) all programs.
Tobias
PS: I have filled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45308
Jakub already provided a patch - though I think one should do some more
changes to make the program faster (avoiding a temporary variable).
Clive Page
Thanks for the extremely rapid response.
In message <4C6A8FC3...@net-b.de>, Tobias Burnus <bur...@net-b.de>
writes
>If you fill the string with data before calling DATE_AND_TIME, you see
>that gfortran (NAG f95 v95 and ifort 11.0) only touch the the first
>characters while g95 (openf95 and pathf95) pad the output.
Indeed.
>I read the standard such that the processor (compiler) should only set
>the first characters and that padding is not supposed to happen:
>
>F95, 13.14.27: "DATE [...] Its leftmost 8 characters are assigned a
>value of the form CCYYMMDD [...] If there is no date available, they
>are assigned blanks."
I think the problem is that it does not say what happens to characters
after the first 8 - it doesn't actually specify that they be left blank.
I expected that an intrinsic procedure with a character argument would
declare its length to be (*) i.e. length assumed from the actual
argument, but of course that is not specified by the Standard, or that
it would behave as strings returned by the INQUIRE statement do, where
blank padding is required. I have used several other compilers for
Fortran90 and they all appear to apply blank padding for DATE_AND_TIME,
even if that is not clearly required.
>This restriction is gone in Fortran 2003 and 2008 and, thus, I agree
>that padding should happen in Fortran 2003/2008. From the standard:
Glad you agree with me on that.
>This seems to be one of the incompatible changes between Fortran 95 and
>2003.
Again, that is a matter of interpretation of the Fortran90 Standard. It
is good that the vagueness is cleared up in 2003/2008 Standards.
>PS: I have filled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45308
>Jakub already provided a patch - though I think one should do some more
>changes to make the program faster (avoiding a temporary variable).
Thanks very much.
--
Clive Page
Richard Maine
> In message <4C6A8FC3...@net-b.de>, Tobias Burnus <bur...@net-b.de>
> writes
> >F95, 13.14.27: "DATE [...] Its leftmost 8 characters are assigned a
> >value of the form CCYYMMDD [...] If there is no date available, they
> >are assigned blanks."
>
> I think the problem is that it does not say what happens to characters
> after the first 8 - it doesn't actually specify that they be left blank....
...
> >This restriction is gone in Fortran 2003 and 2008 and, thus, I agree
> >that padding should happen in Fortran 2003/2008. From the standard:
...
> Again, that is a matter of interpretation of the Fortran90 Standard. It
> is good that the vagueness is cleared up in 2003/2008 Standards.
I'd agree. While I don't remember anything specific about this
particular case, it looks to me like an ambiguity that got cleaned up,
probably intentionally.
I would not, by the way, call it an incompatibility between f90/f95 and
f2003. Since the f90 and f95 standard did not specify, a portable
f90/f95 program could not count on the behavior, even among f90/f95
compilers. F2003 adds no incompatibility here. It just specifies that
compilers had to take one of the options that they could have taken in
f90/f95. While it is true that this could break existing codes, those
existing codes would have already been broken in terms of portability in
f90/f95.
Admitedly, my viewpoint on what to call an incompatibility seems not to
be universal. I don't want to go drag out the exact citations (too much
work before coffee), but I recall at leas one, and possibly a few cases
where the standard itself refers to something simillar as an
incompatibility, even though it just specified something that portable
f77 programs already had to allow for. In fact, in those cases, actual
f77 compilers did have enough variation that programs assuming anything
other than what f90 specified were nonportable in substantial practice.
When I complained that the characterization as an f90 incompatibility
was inaccurate, I got insufficient support to change the standard's
description.
I think that the real reason (probably even explicitly stated during
discussion) was as "defense" for vendors who wanted to be able to
"blame" the standard for making an incompatible change. Telling
customers that their code was already nonportable was not popular among
the non-negligable set of customers who claimed not to care about
portability, but only about their code working on the one compiler they
used. Vendors have been know to deliberately keep actual compiler bugs
in their compilers (at least as an option) for simillar reasons. If
enough influential (and rich) customers depended on the bug and would
complain about it being fixed, then vendors sometimes pay attention.
Of course, pointing to the standard doesn't necessarily placate such
customers, but perhaps it can deflect their wrath elsewhere if the
vendor can claim that "the devil^h^h^h^h^hstandard made him do it."
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain