On Wed, Dec 12, 2018 at 11:37:23AM +0000, Mark Eggleston wrote:
> Before delving into the code to make changes to handle the case when passing
> a variable into transfer instead of a literal I revised the the test cases.
> The results indicate to me that this patch as originally intended is
> erroneous.
>
> When a character literal is assigned to character variable e.g.
>
> character(len=8) :: a
> a = 'ab'
>
> The value is padded with spaces.
Sure, that is the standard behavior of character assignments.
What we are talking about is the case when transfer is used from a smaller
object to a larger result, whether it is e.g. 'ab' literal or character(len=2)
variable. SOURCE doesn't have to be a character scalar (or array), it can
be anything.
The Fortran standard says here:
"If the physical representation of the result is longer than that
of SOURCE, the physical representation of the leading part is that of SOURCE
and the remainder is processor
dependent."
Current gfortran choice of the processor dependent is 0 if SOURCE is a
constant and uninitialized bytes if it is not a constant.
So, does Oracle fortran / ifort etc. pad with spaces only if SOURCE has
character type, or in other cases too?
What about:
integer(kind=2) :: a
a = -1
print *, transfer (1_2, 1_8), transfer (a, 1_8)
end
?
Jakub
