[J3] Question about the result of the SIZE= specifier in nonadvanced READ

[Daniel Chen]

Hi Malcolm,
Thanks for the further explanation. It helps a lot!

Daniel

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org>
Date: Saturday, August 16, 2025 at 12:41 AM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: [EXTERNAL] Re: [J3] Question about the result of the SIZE= specifier in nonadvanced READ
Hi Daniel, I think you did not understand correctly. He said the input was invalid. I agreed with that assertion so did not add anything further. It seems that further explanation is needed, so here goes… Invalid input in older versions of the

Hi Daniel,

I think you did not understand correctly. He said the input was invalid. I agreed with that assertion so did not add anything further.

It seems that further explanation is needed, so here goes…

Invalid input in older versions of the standard made the entire program non-conforming, and anything could happen. The comma could be counted, the comma could be ignored, the comma could count as a billion characters, or the processor could turn your computer into a frog. ANYTHING.

Invalid input in the current standard does this: “If the input field does not have one of the standard forms, and is not acceptable to the processor, an error condition occurs.”

That means that if the processor has an extension that permits a comma in the field, the comma would count as a character being transferred. If it does not have such an extension, the program would be terminated because the error condition is not caught by ERR= or IOSTAT=.

The third possibility would be that the processor does not have a (deliberate) extension, but does have a bug in that it did not notice the invalid format. It is not exactly unknown for processors to have bugs… but if so, the processor was conforming to older editions of the standard but is no longer standard-conforming in this respect.

With the current standard, I do not see any standard-conforming interpretation where there is no error but the comma does not count as a character transferred by the edit descriptor – the only exception is for the blank padding characters inserted by PAD=’YES’.

Finally, I note that in the case where an error condition is raised (i.e. the processor spots the invalidity and does not have a deliberate extension), the SIZE= variable is defined by the characters transferred so far - up until the error happens – see 12.11.2p2 item (5), so that would not count the comma (and maybe not any of the preceding characters for that input item since it was unfinished, so whether those characters “got transferred” is debatable). Furthermore, *ALL* of the input variables become undefined – see 12.11.2p2 item (6). I guess we made the SIZE= variable defined so that the user would get a clue as to where the invalidity in the input occurred, but it doesn’t look very robust or useful to me…

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Daniel Chen via J3
Sent: Friday, August 15, 2025 11:36 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Daniel Chen <cdchen at ca.ibm.com>
Subject: Re: [J3] Question about the result of the SIZE= specifier in nonadvanced READ

Thanks Bob.

If I understand what you said correctly, the `comma` shouldn’t’ be counted, so the output of the test code should be
“
12
11
“

Because of each record of the first read has “1.2 “, so 3 record has 12 characters
For the 2nd read, the first two records have the same “1.2 “, but the last one only has “1.2”, 3 characters. So the size is 11.

Thanks
Daniel

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of Robert Corbett via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: Wednesday, August 13, 2025 at 6:56 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Robert Corbett <rpcorbett at att.net<mailto:rpcorbett at att.net>>
Subject: [EXTERNAL] Re: [J3] Question about the result of the SIZE= specifier in nonadvanced READ
I am not aware of a change to the standard that makes it acceptable for a comma to appear in a field read under F editing unless the decimal edit mode is COMMA. Bob Corbett On Aug 13, 2025, at 11: 02 AM, Daniel Chen via J3 <j3@ mailman. j3-fortran. org>

I am not aware of a change to the standard that makes it acceptable for a comma to appear in a field read under F editing unless the decimal edit mode is COMMA.

Bob Corbett

On Aug 13, 2025, at 11:02 AM, Daniel Chen via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

Hello all,

What should be the correct output from the following code?

```
    character(13) c
    real r1(3), r2(3)
    integer i1, i2

    c = '1.2, 1.2, 1.2'

    write (2, '(2a)') c, ' '

    write (3, '(2a)') c, ','

    rewind 2
    rewind 3

    read (2, '(3F5.1)', advance='no', size=i1) r1
print*, i1

    read (3, '(3F5.1)', advance='no', size=i2) r2
print*, i2


    end
```

The standard says the following about the SIZE= specifier
```
The SIZE= specifier in an input statement causes the variable specified to become defined with the count of

the characters transferred from the file by data edit descriptors during the input operation. Blanks inserted as

padding are not counted.

```

Different compiler gives different output. Some counts comma and some also counts blank.

What is the standard conforming output of this code?

Thanks,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20250818/46b534a6/attachment-0001.htm>