Spaces as zeroes

How to avoid treating spaces as zeroes when reading integer number like read(11,*) ? I forgot about such unusual behavior of Fortran and got caught 😦

Reading numbers with the implied format ('*') has no effect from spaces.

Here's the output from the program below. I input a '1' with trailing spaces, the '2' with leading space, and the '3 4 5 6' just to have it only read the first one.

1 1 2 2 3 4 5 6 3

	program main
	integer:: i=0
        do while (i >-99)
        read (1,*)i
        print *,i
        end do       
        end

Not getting that there is an issue.

The B, BN, and BZ specifiers control interpretation of embedded and trailing blanks for numeric input, but you should not have to use these for read(11,*).

Thanks for suggestions!

I used internal read like this ( i expected to read floating point number but it was by mistake integer)

character*120 text
text='1            2           3'
read(text(1:6),*) f
Print*,f
pause
end

And indeed, in this small demo i get no such issue. But in the larger code the only way i removed this issue was to separate two cases: if it is integer use strictly integer read like this

character*120 text
text='1            2           3'
read(text(1:6),'(i10)') i
Print*,i
pause
end

and for FP floating point accordingly floating point with * like my first example

Looks like got some devilry somewhere. Again 😦

Dan, I am still confused by your examples given.

If one uses the '' format specifier, the results of reading into an integer or a real is the same. '1' is interpreted properly because the '' stops scanning the string at the first non-numeric character. As far as the READ is concerned, there is no difference between the '1' as an integer or a real. It is the data type in the READ itself that determines how the data are to be scanned/stored.

When reading using an explicit format like '(i10)', the rule used is different. In that case, the entire 10 characters is used, with spaces becoming zeroes. This is per the standard. If you wish it to be interpreted in a different way, then you have to use Ken's suggestion. And I agree with Ken, a '*' does what you wish it to so far as your simple example goes.

One thing I've done is to use the ERR= or IOSTAT= to check the data type of an input. I extract a portion I wish to 'analyze' into a string, then subject it to the appropriate READ (using the '*' format specifier) per the appropriate type and including the ERR= and/or IOSTAT=. If it fails, then there is an issue with the data. If it succeeds, then we're OK, I store the result and move to the next item. This is used almost exclusively with user created inputs.

Using your example, if you specified a decimal point after the '1', then the integer read fails, while the real read succeeds.

Needless to say i am confused even more. So for a while i check for the point in the number, and if it exists, i read it as real number, if absent - as integer. When i will have more time we will return to this example, i have several places in my codes similarly crazy, and some exist for months but i do not have any time to dig for the reason, it is easy just to find the workarounds which somehow work. This is not just me who got such present from the devilry. Our people got some experimental numbers which are 15x larger than commonly reported before and now i am getting the simulations which do not confirm any of sides 😃