replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Bug with zero size arrays
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bug with zero size arrays

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK
PostPosted: Fri Jul 29, 2011 5:26 pm    Post subject: Bug with zero size arrays Reply with quote
I should be able to pass zero size arrays to a function. But the compiler removes the call, with the comment:

comment 338 - This expression contains a zero-sized rank, so will do nothing

However, this is not the correct behaviour according to the standard. One might want to do something useful if the array is zero size. In particular, one might want to write defensive code which copes with such cases.

I have checked the standard, and you should definitely allow zero sized arrays to be passed.

I discovered this while implementing quickselect.

Example code (quick select with parts removed):

Code:

module statistics
contains
   ! Finds kth smallest (i.e. kth order statistic) amongst an array of values
   function kth_smallest(x, k)

      integer, intent(in) :: k
      real, intent(in) :: x(:)
      real kth_smallest

      ! Return maximum value if k is larger then the array size.
      ! This special case should also be triggered if the array has zero size
      ! in which case, maxval should return -HUGE(1.0) for the default real
      ! kind.

      if (k > size(x)) then
         kth_smallest = maxval(x)
         return
      end if

      ! Return minimum value if k == 1

      if (k == 1) then
         kth_smallest = minval(x)
         return
      end if
     
      ! Assert 1<k <= size(x).
      ! Find kth order statistic using the quickselect algorithm
   
      !** Code not shown

   end function kth_smallest

end module statistics

program test
   use statistics
   real :: x(7) = (/ 1.0, 3.0, 2.0, 4.0, 7.0, 6.0, 5.0/)
   real :: y = 0.0
   ! Test with zero size array section
   y = kth_smallest(x(2:1), 3)  !!<< Bug. When I step with the debugger this is not called.
   ! Should print -Huge(1.0) but doesn't
   print *, y
end program test


David.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

Last edited by davidb on Sat Jul 30, 2011 8:23 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
PostPosted: Sat Jul 30, 2011 7:07 am    Post subject: Reply with quote
Works OK for me. Which version of FTN95 are you running and under what configuration (CHECKMATE etc; Win32 or .NET)?
Back to top
View user's profile Send private message AIM Address
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK
PostPosted: Sat Jul 30, 2011 8:37 am    Post subject: Re: Reply with quote
PaulLaidler wrote:
Works OK for me. Which version of FTN95 are you running and under what configuration (CHECKMATE etc; Win32 or .NET)?


First, I apologize for missing of the contains statement before the function definition -- I have edited the above now to correct this.

I am using version 6.10.0.

I get the same behaviour with Checkmate, Debug, Release configurations for Win32 and .NET.

I get the comment message above and the code prints 0.00000 instead of -3.402823E+38.

I don't mind the comment, its the fact that it removes the call that is not correct. When I step in the debugger, the line is just passed over. When I look at the assembler the code is not there!

If I change things so the compiler cannot know its a zero size array at compile time then it works, e.g.

Code:

integer i
print *, 'Enter upper bound of 1'
read *, i !<< enter 1

! ...

y = kth_smallest(x(2:i), 3)
print *, y !< prints -3.402823E+38


David.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
PostPosted: Sat Jul 30, 2011 2:16 pm    Post subject: Reply with quote
That's strange. I am using XP. I will try other operating systems.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
PostPosted: Sun Jul 31, 2011 6:08 am    Post subject: Reply with quote
The problem does not occur in my current development version of FTN95 but it does occur for me in version 6.10. I cannot think of a connection with a recent fix but there we are.
Back to top
View user's profile Send private message AIM Address
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK
PostPosted: Sun Jul 31, 2011 11:45 am    Post subject: Reply with quote
Thank you. Hopefully it was connected with another fix or development you have made and so will work correctly with the next release.

David.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group