Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
92 Views

Internal write issue

Hello,

I used to be able to use code similar to:

    program TstString
    implicit none

    ! Variables
    Character(7) :: String1
    Character(15) :: String2
    Integer(4) :: L
    
    ! Body of TstString
    String1 = "Check: "
    String2 = "True"
    L = LEN_TRIM(String2)
    Write(String2,"(A7,A5)") String1,String2(1:L)

    end program TstString

In the past the result was the string "Check: True "

Now I get "Check: Chec "

Apparently nowadays String1 is first written to String2 before both String1 and String2 are written to String2.

Is this intended behavior?

With best regards,

Walter Kramer

0 Kudos
13 Replies
Highlighted
92 Views

Steve may be able to answer

Steve may be able to answer why. My guess is use of String2 on both sides is undefined (implementation behavior)

To accomplish the same thing:

String2 = String1(1:7) // String2(1:5) ! concatenate sub-strings

Jim Dempsey

 

0 Kudos
Highlighted
Retired Employee
92 Views

My opinion is that this is a

My opinion is that this is a nonconforming program and the result is unpredictable. However, I can't find words in the standard that cover this, and will ask.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Black Belt
92 Views

Section 9.6.4.5.1, rule 6 of

Section 9.6.4.5.1, rule 6 of the Fortran 2008 standard says:

If an internal file has been specified, an input/output list item shall not be in the file or associated with the file.

0 Kudos
Highlighted
Retired Employee
92 Views

Yep - in F2018 that is 12.6.4

Yep - in F2018 that is 12.6.4.5.1p6

So, nonconforming, though compilers are not required to diagnose this. Results are unpredictable.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
92 Views

Thanks all for your support.

Thanks all for your support.

This approach has been in the code of one of our programs for appr. 15 years. I noticed that it didn't work anymore after recompiling with version 19.0.5.

I don't remember which was the last version I used for compiling the code that made it function as I intended.

Anyway introducing a conforming approach shouldn't be too difficult. I suppose the concatenation of sub-strings will do the job.

Walter Kramer

 

0 Kudos
Highlighted
92 Views

Quote:Steve Lionel (Ret.)

Steve Lionel (Ret.) (Blackbelt) wrote:

Yep - in F2018 that is 12.6.4.5.1p6

So, nonconforming, though compilers are not required to diagnose this. Results are unpredictable.

Greetings,

That's correct, from the "compiler's point of view". It is "by the book" after all.

However, let me humbly comment something here. It's not exactly the same from the "programmer's point of view". It would be nice if the compiler at least warned you of this (unpredictable) behavior. Unpredictable outcome can never be the developer's intention!

It would also help migrating such a program from an earlier intel fortran compiler, which used to yield different results. After all, to find and remedy such code you have no other choice but test-debug runs, which can be time consuming and tricky.

And it's not the best surprise to find after having upgraded to the brand new compiler!

0 Kudos
Highlighted
Valued Contributor II
92 Views

It doesn't show any message

It doesn't show any message with standards checking on.

 

0 Kudos
Highlighted
92 Views

>>It would also help

>>It would also help migrating such a program from an earlier intel fortran compiler, which used to yield different results.

While this may be helpful in some cases, it is meaningless or even contra-helpful in other cases. In your specific case, you have a WRITE statement that is equivalent to a function call with an argument alias. This is forbidden (without attribute qualification). In this specific case, a "warn all" option (c/s)hould have issued a warning.

In different cases, for example where a poorly written convergence routine, produces drastically different results, you'd be asking the compiler to identify poorly written code.

Jim Dempsey

0 Kudos
Highlighted
Retired Employee
92 Views

Quote:andrew_4619 wrote:

andrew_4619 wrote:

It doesn't show any message with standards checking on.

As I wrote above, compilers aren't required to check this, though in this case it is possible and reasonable to do so.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Valued Contributor II
92 Views

So is standards checking in

So is standards checking in ifort meant to check only what the standards says it must check (do the standards even have such a requirement?) or is it meant to check (as much as is possible/practical) that the code is standard conforming to help users? I assumed the later which was the basis of the #8 comment.

0 Kudos
Highlighted
Retired Employee
92 Views

The goal is to check as much

The goal is to check as much as is feasible, with the minimum being what the standard requires. ifort goes way beyond that, as do most compilers, but there hasn't been a concerted effort to check each and every possible thing. It is worth raising this as a feature request to Support, as it's something easy to overlook in the implementation.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor I
92 Views

Write(String2,"(A7,A5)")

Write(String2,"(A7,A5)") String1,String2(1:L)

This is analagous to the problem of updating variables in programs, you create a dummy variable, string 3 and then set string 2 to string 3

 

i = 1

j = 2

let dum = j

j = i

i = j

 

0 Kudos
Highlighted
92 Views

In C programming you had

In C programming you had memcpy and memmove. memcpy is undefined when strings overlap whereas memmove will check for overlap and adjust code accordingly. Fortran is just like memcpy (undefined).

C would not complain of overlapping strings.... because you may have expressly desired to duplicate a sub-string many times.

Jim Dempsey

0 Kudos