[FORTRAN] Assigning bad values in arrays

[Matterwave]

Hi, I just realized that I have been making bad array assignments in my code. Specifically, I think I have been assigning to slots that the array does not have. For example, I might declare an array:

int,parameter :: nflavor=3
int,parameter :: nflavor2=nflavor*2
real,dimension(nflavor)::x
real,dimension(nflavor2)::y

And then assign values of y from values of x in such a fashion:

do i=1,nflavor
y(i)=x(i)
end do

do i=nflavor+1,nflavor2
y(i)=x(i)
end do

So for the second do-loop, I should be going over values of i for slots that x doesn't have, right?
I realized that what I should have written was something like:

do i=nflavor+1,nflavor2
y(i)=x(i-nflavor)
end do

Now that I think about it, I would have guessed I should have incurred a bunch of compile-time or at least run-time errors. However, with these errors, the code actually still ran. I did not get compile or run-time errors using these faulty array assignments. Can anyone guess what Fortran has been doing?

 

[Mark44]

What values are in y(4), y(5), and y(6)? I'm guessing they are garbage values; i.e., whatever happens to be in memory following x(3).

 

[Matterwave]

Ah I see. No wonder I was getting some bogus values...I would have hoped to get a compiler error or at least a warning of some sort...but I guess not? What if I had written it the other way around though, like:

do i=nflavor+1,nflavor2
x(i)=y(i)
end do

Now is it assigning random memory addresses with values from y(i)?

 

[Mark44]

Ah I see. No wonder I was getting some bogus values...I would have hoped to get a compiler error or at least a warning of some sort...but I guess not? What if I had written it the other way around though, like:

do i=nflavor+1,nflavor2
x(i)=y(i)
end do

Now is it assigning random memory addresses with values from y(i)?

Yes, which is not a good thing to do.

 

[Matterwave]

Yes, which is not a good thing to do.

It seems like...there should be a compiler warning for issues such as this. I hope I haven't made this error in more places than I can remember! D: I've fixed it everywhere I can remember making such assignments.

 

[Mark44]

I did a quick check of the the GNU Fortran compiler docs, and I didn't see any warnings that were specific to indexing an array beyond its bounds.

 

[Matterwave]

I did a quick check of the the GNU Fortran compiler docs, and I didn't see any warnings that were specific to indexing an array beyond its bounds.

Haha, perhaps they should implement that...seems quite dangerous! And it's a pretty easy error to make if you ask me.

 

[jtbell]

When you compile the program, you can tell gfortran to generate runtime code that checks for out-of-bounds array indexes, by using the -fbounds-check compiler option. See

http://linux.die.net/man/1/gfortran

(down towards the end of the page)

Fortran programs don't do this by default because the extra code makes the program run slower. Normally you use this only when testing and debugging. When you're satisfied that the program is running correctly, with all arrays staying within bounds, you can re-compile with bounds checking turned off, if speed is important.

 

[Matterwave]

When you compile the program, you can tell gfortran to generate runtime code that checks for out-of-bounds array indexes, by using the -fbounds-check compiler option. See

http://linux.die.net/man/1/gfortran

(down towards the end of the page)

Fortran programs don't do this by default because the extra code makes the program run slower. Normally you use this only when testing and debugging. When you're satisfied that the program is running correctly, with all arrays staying within bounds, you can re-compile with bounds checking turned off, if speed is important.

Ah, I thought that the bounds checking would have been really simple, once over look, like a syntax error or something. I guess it's not always so easy? Thanks for the info! :)

 

[jtbell]

Bounds checking has to be done at run time not compilation time, because array indices are usually variables. The compiler often can't easily figure out what values a variable will contain when you run the program. Sometimes it's impossible, e.g.:

      real frammis(10)
      integer n
      print *, 'Which frammis do you want? '
      read *, n
      print *, 'OK, here it is: ', frammis(n)

 

[Matterwave]

Bounds checking has to be done at run time not compilation time, because array indices are usually variables. The compiler often can't easily figure out what values a variable will contain when you run the program. Sometimes it's impossible, e.g.:

      real frammis(10)
      integer n
      print *, 'Which frammis do you want? '
      read *, n
      print *, 'OK, here it is: ', frammis(n)

I see. But this requires some kind of input external to the program, in which case it would be good for the programmer to put some fail safes e.g.

      real frammis(10)
      integer n
      print *, 'Which frammis do you want? (integer from 1 through 10)'
      read *, n
      if (n .ge. 1 .and. n .le. 10)
      print *, 'OK, here it is: ', frammis(n)
      else
      print *, 'Please enter a valid integer from 1 through 10'
      read *, n
      end if

It seems though that Fortran should be able to easily check at compile time any instances of bad array bounds where the arrays are both not allocatable and its array assignments in the code are all within the code itself and not read through the console or through a file. Such as the instances in my code where I had loops go outside of array bounds.

 

[a_potato]

That is somewhat over the top for a compiler. Also, any code worth it's salt and written to actually do something useful would not have many cases where array bound errors could be spotted at compile time

 

[Matterwave]

That is somewhat over the top for a compiler. Also, any code worth it's salt and written to actually do something useful would not have many cases where array bound errors could be spotted at compile time

Thanks for insulting my code. :s:L

 

[SteamKing]

A good compiler should be able to figure out what the programmer really wants to do, instead of just doing what the programmer has programmed.