The following notation specifies the storage size for a type:
generic-type must be a generic type--one of
n must be one or more digits comprising a decimal
integer number greater than zero.
Use the above form where a type name is valid.
notation specifies that the amount of storage
occupied by variables and array elements of that type is n
times the storage occupied by a
This notation might indicate a different degree of precision and/or range for such variables and array elements, and the functions that return values of types using this notation. It does not limit the precision or range of values of that type in any particular way--use explicit code to do that.
Further, the GNU Fortran language requires no particular values
for n to be supported by an implementation via the
on all systems, for example,
but not all implementations are required to do so, and
is known to not support
REAL*1 on most (or all) systems.
As a result, except for generic-type of
uses of this notation should be limited to isolated
portions of a program that are intended to handle system-specific
tasks and are expected to be non-portable.
(Standard FORTRAN 77 supports the
CHARACTER, where it signifies not only the amount
of storage occupied, but the number of characters in entities
of that type.
However, almost all Fortran compilers have supported this
notation for generic types, though with a variety of meanings
Specifications of types using the
always are interpreted as specifications of the appropriate
types described in this document using the
notation, described below.
While use of this notation is popular, it doesn't serve well in the context of a widely portable dialect of Fortran, such as the GNU Fortran language.
For example, even on one particular machine, two or more popular
Fortran compilers might well disagree on the size of a type
is known to be disagreement over such things among Fortran
compilers on different systems.
Further, this notation offers no elegant way to specify sizes
that are not even multiples of the "byte size" typically
Use of "absurd" values (such as
certainly be possible, but would perhaps be stretching the original
intent of this notation beyond the breaking point in terms
of widespread readability of documentation and code making use
Therefore, this document uses "star notation" only on occasion for the benefit of those readers who are accustomed to it.