Size and 64 bits

My recollection is that you can get an unnecessary copy-in and/or and unnecessary copy-out when an interface is omitted. I don't think that this is particularly related to the INTENT attribute.

The important point is that users can forget to provide and an interface when passing assumed-shape arrays and that this can cause problems of one kind or another.

In this context I have used 'interface' to mean either (a) a coded INTERFACE/END INTERFACE or (b) a USE of a module subprogram.

Does anyone object if we change to

1. /SIZE_IOS being an alias for /SIZE32 with only /SIZE_IOS appearing in the documentation,

2. /IOS implying /SIZE_IOS?

You mean /SIZE_ISO and /ISO I believe 😉

These options influence the integer kind returned for the SIZE, UBOUND and LBOUND intrinsic functions.

There are 3 parts to this proposal.

[u:e243d7a519]For the 32 bit compiler.[/u:e243d7a519]

The functions return a value with the same kind as default integer (as they do now).

[u:e243d7a519]For the 64 bit compiler enabled with /64[/u:e243d7a519]

The functions return a 64 bit value by default (as they do now).

The functions return a default integer value when /ISO or /SIZE_ISO is used.

The default integer kind is 32 bits unless /DEF_INT is used to change it.

[u:e243d7a519]/SIZE32[/u:e243d7a519]

/SIZE32 is an alias for /SIZE_ISO.

I would be happy. 😃

Paul,

I would be happy with any approach that provided for an INTEGER*8 response for /64 coding, even the F03 format of SIZE ( a, [,DIM,KIND=n]). The problem is always providing '=n', as values of n= 1,2,3,4,7 or 8 can be a possibility, with =4 being the ambiguous one. =7 is a good non-standard outcome that may get more protests.

The changes outlined above have now been implemented for the next release of FTN95.

1. SIZE, UBOUND and LBOUND can now accept the optional KIND argument.

2. /SIZE32 has become /SIZE_ISO.

3. /ISO now implies /SIZE_ISO.

4. By default SIZE returns a 64 bit value in 64 bit compilations.