/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 (??)

      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

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.

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.

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.

Specifically INTEGER and CHARACTER variables can generate false positives with INTEGER1 and CHARACTER1 being the worst cases (1 in 256).

REAL, COMPLEX and LOGICAL values should not generate false positives in normal usage.

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.