- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
just wonder if there is a way to pick-up integer miss-match (see simple example below) as it might frequnetly appear when porting from Win32 to x64. Any suggestions how I can find such flaws? Useful compiler options, etc..
program test
integer(4) i4
integer(8) i8
i8 = 2
do i = 1,19
i4= i8 ! here is the miss-match that leads to problems for i>10
write (*,*) 'i4= ', i4, '; i8=', i8
i8 = 10*i8
enddo
read(*,*)
end program test
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sometimes you can benefit by obtaining a second opinion using a different compiler:
misi.f90:11:12:
i4= i8 ! here is the miss-match that leads to problems for i>10
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]
says Gfortran.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is not common for Fortran programs to have such issues going from 32-bit to 64-bit, other than if you declare integers that are supposed to hold addresses. The program you show would fail on either 32-bit or 64-bit.
What you're asking for, I think, is detection of integer overflow, not "mismatch". Fortran has defined semantics for mixed-kinds and numeric types. We don't detect integer overflow, though you're not the first to ask for it. I'll add your request to the list.
This is why it is generally recommended to use named constants, or intrinsics, for kinds in declarations. For example, if you are doing Windows programming we provide a HANDLE kind that is correct for both 32-bit and 64-bit. We also have the INT_PTR_KIND() intrinsic that returns the kind of an address. (There is also C_INTPTR_T in module ISO_C_BINDING.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve!
That was just an example what I mean and I know that the code fails for both Win32 and x64. Also, I'm fully aware of the HANDLE kind but the original developer did not use it The code was written for Win32, and many local variables in fact hold addresses. Now I try to spot them, and the most important question is: what is the most convenient way?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, if you're passing these to Windows API routines, then the mismatch in the interface will cause a compile error. But if you're assigning values, there is no good way at present to alert you to the problem. We have seen suggestions for an optional "usage warning" any time there is an implicit type/kind conversion, but I don't see that happening for a while.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve!
also tried with \warn:all but this implicit type conversion remains silent. Guess I'll have to go through thousands of code lines and check it manually . It's actually wired that no such warning exists, isn't it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sometimes you can benefit by obtaining a second opinion using a different compiler:
misi.f90:11:12:
i4= i8 ! here is the miss-match that leads to problems for i>10
1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]
says Gfortran.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As I mentioned, we don't give warnings for usage that is specified in the standard, even though it might be problematic. I expect that in the future we will start to do so. As mecej4 says, gfortran and some other compilers do have such an option.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks guys - guess I'll use Gfortran to assist me in finding these flaws.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page