Reading missing / blanks as logical .false.
Tobias Burnus
I have an old program which assumes that blanks are read as .false. If I
read the standard correctly, reading the integer "" as 0 is required by
the standard but reading the logical "" as .false. is not.
(Interpretation help: Is it allowed for a standard conforming compiler
to read "" as .false. or does the standard mandate that an error needs
to be reported?)
My question is now, how to best replace
READ (5,8010) latnam,namgrp,invs,zrfs,l_J
8010 FORMAT (a3,1x,a4,6x,l1,6x,l1,31x,l1)
by something which is standard conforming?
Tobias
Arjen Markus
I do not know the answer to your blank as .false. question, but why
not
read the logical variables as character strings of 1 long and then
invs = verify(a_invs, 'tT') > 0
(or something similar)
Regards,
Arjen
dpb
> Hello,
>
> I have an old program which assumes that blanks are read as .false. If I
> read the standard correctly, reading the integer "" as 0 is required by
> the standard but reading the logical "" as .false. is not.
I read the CVF description of input processing for L edit descriptor and
it says the following--
> On input, the L data edit descriptor transfers w characters from an
> external field and assigns their logical value to the corresponding I/O
> list item. The value assigned depends on the external field data, as
> follows:
>
> .TRUE. is assigned if the first nonblank character is .T, T, .t, or
> t. The logical constant .TRUE. is an acceptable input form.
>
> .FALSE. is assigned if the first nonblank character is .F, F. .f, or
> f, or the entire field is filled with blanks. The logical constant
> .FALSE. is an acceptable input form.
>
> If an other value appears in the external field, an error occurs.
The section wasn't marked as having any extensions so I'd presume it's
Standard-conforming...
Again, that's based on the DEC/Compaq/now-Intel team's
interpretation/documentation, not the root standard.
--
Tobias Burnus
> Tobias Burnus wrote:
>> I have an old program which assumes that blanks are read as .false. If I
>> read the standard correctly, reading the integer "" as 0 is required by
>> the standard but reading the logical "" as .false. is not.
> I read the CVF description of input processing for L edit descriptor and
> it says the following--
[...]
>> .FALSE. is assigned if the first nonblank character is .F, F. .f, or
>> f, or the entire field is filled with blanks.
>
> The section wasn't marked as having any extensions so I'd presume it's
> Standard-conforming...
Assuming the latter is quite dangerous. The standard (F2003) has for
numerical values something similar ("10.6.1 Numeric editing": "On Input
[...] A field containing only blanks is considered to be zero.") but for
logical it merely has:
"The input field consists of optional blanks, optionally followed by a
period, followed by a T for true or F for false. The T or F may be
followed by additional characters in the field, which are ignored. A
lower-case letter is equivalent to the corresponding upper-case letter
in a logical input field."
Thus the blank = .false. is a vendor extension.
With regards to the standard, my question was (and is) whether a
compiler which accepts blank = .false. is standard conforming or whether
it violates some constrain which requires an error in this case.
Tobias
Steve Lionel
> I read the CVF description of input processing for L edit descriptor and
> it says the following--
...
>> .FALSE. is assigned if the first nonblank character is .F, F. .f, or
>> f, or the entire field is filled with blanks. The logical constant
>> .FALSE. is an acceptable input form.
>
> The section wasn't marked as having any extensions so I'd presume it's
> Standard-conforming...
>
> Again, that's based on the DEC/Compaq/now-Intel team's
> interpretation/documentation, not the root standard.
The standard does not specify the behavior if the field is all blanks -
the wording in the standard requires there to be a T or F following
optional blanks and an optional dot.
Do not assume that the lack of a notation for an extension means that it
is not an extension. I will point this one out to our writers.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Steve Lionel
> With regards to the standard, my question was (and is) whether a
> compiler which accepts blank = .false. is standard conforming or whether
This not a violation of a numbered syntax rule nor a constraint, so the
compiler is not required to diagnose this. In fact, there are no
run-time behaviors I can think of that a compiler is required to
diagnose. Few if any compilers offer standards-conformance checking for
I/O behavior. (I don't know of any, but there may be one out there. Note
that an implementation which doesn't support an extension at all doesn't
count.)
As is often said in this group, the standard defines the behavior of a
standard-conforming application. What a "processor" does in the
presence of a non-standard source or run-time input is unspecified by
the standard. A compiler is standard-conforming if it processes a
standard-conforming application according to the standard. (There are
also some requirements for the ability to diagnose some non-standard
syntax.)
dpb
...
> Do not assume that the lack of a notation for an extension means that it
> is not an extension. I will point this one out to our writers.
...
OK, good to know it isn't intended to be a design constraint in the
documentation... :) (Not that I ever felt it was "guaranteed")
But, it generally holds so I have become _quite_ lazy in counting on
the shading/other indications to let me know rather than trying to
decipher the Standard. I do know (as noted in earlier response) that's
relying on somebody having made a notation that a feature is an
extension so don't feel betrayed or that it's a major fault on such an
occasions as this...
--
Dave Allured
Actually your original question was "how to best replace".
So what does "best" mean to you? I infer that you are concerned about a
real possibility of blanks in logical fields.
One option is to do something standard conforming, yet work exactly like
the original code. For this, just read the logicals as characters
first, then convert expected characters, including blanks, to the
desired logical values. Arjen showed a nice way to do this in one line
with verify() (with which I am unfamiliar). There is a simple way to do
this with index(), too.
However, "best" might be to go a step farther and add some quality
control diagnostics. This might be my choice for a general "production"
environment, depending on what kind of screwed up input files I was
expecting. In pseudo code:
if c_invs is T or t, then invs = true
else if c_invs is F or f, then invs = false
else if c_invs is blank, then handle_blank
else if c_invs is other, then handle_other
The exception handlers could do anything from silently inserting the
desired logical value or counting occurrences of unexpected characters,
to printing an error message and halting immediately. You get to
decide. HTH.
--Dave
Terence
Tobias, this is the same as the problem I posted on how to distinguish
a real value of 0.0 from a blank field in an input operation.
The specific solution, if the format is porvided by you, it to read
the input into a character string and then read the character string
for you logic values (and any others). But for any logical value of
FALSE, you can then check the field area to see if it was blank
(missing value) or 0 (False).
The general solution (where the user supplies the format statement
externally) is to parse the user's input format, and generate a new
format where all fields become character fields. Then the input
characer string is re-read twice: once with the user format and once
with the 'only-character-field' format. Then the same operation is
applied to any blank fields.