| View previous topic :: View next topic |
| Author |
Message |
Wilfried Linder
Joined: 14 Nov 2007
Posts: 314
Location: D�sseldorf, Germany
|
 Posted: Mon Oct 06, 2014 4:33 pm Post subject: /full_undef problem |
 |
|
I tried to use the /full_undef compiler option and got a problem which might only be a problem of understanding. Can anyone please help? Here is a small example of code. I want to save the image palette rgb_a in another palette rgb_b. Without /full_undef everything runs prefectly, but using this option and then starting the program, an error occurs ("Reference to undefined character", line 27 - the third line from below). But both palettes ARE defined (??)
| Code: | winapp
program test
implicit none
integer*4 i
character*1 rgb_a(3,0:255),rgb_b(3,0:255)
do i = 0,255
rgb_a(1,i) = char(i)
rgb_a(2,i) = char(i)
rgb_a(3,i) = char(i)
end do
call save_pal(rgb_a,rgb_b)
do i = 0,255
print*,i,' ',rgb_b(1,i)
end do
end
subroutine save_pal(rgb_a,rgb_b)
implicit none
character*1 rgb_a(3,0:255),rgb_b(3,0:255)
rgb_b = rgb_a
return
end
|
Thanks in advance
Wilfried |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Oct 06, 2014 7:23 pm Post subject: |
|
|
This looks like a bug. In the line "rgb_b = rgb_a", copying only gets up to 128 on the second index. Probably something to do with signed/unsigned values in the checking of character values.
In the short term you may have to avoid /full_undef. You could do this in this local context now that you are sure that all values are being copied correctly. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Jan 19, 2015 2:40 pm Post subject: |
|
|
It turns out that this is not a bug.
The FULL_UNDEF feature has to use a character value to represent the undefined state and this happens to be 128 which is assumed to be out of range in normal usage. This means that if you assign a character to char(128) and then copy it to another character (when applying /FULL_UNDEF) then you will get the failure. |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
| Posted: Mon Jan 19, 2015 4:03 pm Post subject: |
|
|
| A similar problem could occur with INTEGER and other variable types, since a specific value is used to represent "undefined", but the frequency of such false positives is far smaller than in the character variable case. In general, any code that references a variable that can be set to the entire range of possible values of a specific type will yield a false positive when /FULL_UNDEF is used. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Tue Jan 20, 2015 10:29 am Post subject: |
|
|
Specifically INTEGER and CHARACTER variables can generate false positives with INTEGER*1 and CHARACTER*1 being the worst cases (1 in 256).
REAL, COMPLEX and LOGICAL values should not generate false positives in normal usage. |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Tue Jan 20, 2015 11:21 pm Post subject: |
|
|
I assume with LOGICAL you have "spare" bits in which to encode the undefined/defined status. You only really need 1 bit to code .TRUE. or .FALSE. IF so false positives should be impossible in such variables.
The bit patterns used for real and complex values never seem to show up in my models so I have never had a false positive due to chance.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
