Re: when substring equals string
- From: tholen@xxxxxxxxxxxx
- Date: 10 Dec 2007 18:19:13 GMT
fj <francois.jacq@xxxxxxx> writes:
If one has a character variable:
CHARACTER (LEN=4) :: String
then would the following statement:
READ (1) String(1:4)
be equivalent to:
READ (1) String
A colleague of mine insists that he was able to get a program working,
when compiled on Red Hat Enterprise Linux with Intel's ifort, after
replacing the former with the latter. I don't understand why there
should be a difference.
First of all, I don't like the unit number you are using.
The unit number is attached to a file via an OPEN statement. Pretend
it's unit number 42 if you prefer. I didn't even bother to check the
actual unit number being used by the program, because it's not relevant
to the question.
From a
general point of view, unit indexes less than 8 have often a special
meaning (history of the computer science) :
- 0,1,2 : standard UNIX units (standard in, out,error)
- 5,6 : IBM (I believe) units for standard Fortran input and ouput
- 7 : again the IBM fortran unit for punching
Once attached to a file via an OPEN statement, there should be no
difference in behavior based on the value of the unit number.
Here you assume that the unit 1 is "UNFORMATTED".
There is no assumption. The file is opened as unformatted.
Notice that the UNIX unit 1 is FORMATTED instead ...
Not when unit 1 is attached to a file via an OPEN statement that
specifies unformatted. No doubt you'll now complain because I
didn't show the OPEN statement above. Well, I also didn't show
the rest of the program above, because the rest of the program
isn't relevant to the question, nor is the OPEN statement. The
question is about a character variable, not unit numbers.
A first source of mistake.
No. Get past the unit number, which is identical in both statements,
and look at the part that is different, namely the character variable.
Anyway, let us assume that a correct OPEN statement overrides a
possible default definition of the unit 1 :
OPEN(unit=1,file="my_unformated_file",form="UNFORMATTED")
In that case, the two READ statements you propose are strictly
equivalent.
That's my understanding. Yet it was claimed that the program failed
with the former and worked with the latter.
If the code behavior is not the same, then it means that
another mistake occurred before the read statement.
Like in the way the operator invoked the compiler. The operator was
taking working code and getting it running on a Linux machine. There
is no mistake in the code.
And this previous
error, without immediate symptom, disturbs the code differently just
because the compiler has not produced exactly the same series of
instructions for these two READ statements (as the two read statements
are different but equivalent, a compiler can translate them in the
same manner or not).
There is no previous error in the code. I'm guessing that the
operator did something differently when invoking the compiler, such
as forgetting to specify "-assume:byterecl", but he insists that he
did it the same way each time.
.
- References:
- when substring equals string
- From: tholen
- Re: when substring equals string
- From: fj
- when substring equals string
- Prev by Date: Re: Internal file question
- Next by Date: Re: Portability and kind problems
- Previous by thread: Re: when substring equals string
- Next by thread: Re: when substring equals string
- Index(es):
Relevant Pages
|
