bug in g95 with character arrays?
wim
ifort and gfortran compile the following without complaining:
$ cat mtest.f90
module mtest
implicit none
character(len=5), parameter :: test(5) =
["tan","atan2","atan","sin","asin"]
end module mtest
Not so with g95:
$ g95 -c -o mtest.o mtest.f90
In file mtest.f90:3
character(len=5), parameter :: test(5) =
["tan","atan2","atan","sin","asin"]
1
Error: Element in character array constructor at (1) has length 5
instead of 3
Does the standard say anything about what the compiler should do with
the elements in a character array that have a length shorter than the
one defined by its length, or should i always pad string parameters
with spaces by hand?
Still, this is a bug i think, as g95 doesn't take the declared length
into account but uses the length of the first element in the array?
Greetings,
Wim
Steve Lionel
>
> character(len=5), parameter :: test(5) =
> ["tan","atan2","atan","sin","asin"]
> 1
> Error: Element in character array constructor at (1) has length 5
> instead of 3
>
> Does the standard say anything about what the compiler should do with
> the elements in a character array that have a length shorter than the
> one defined by its length, or should i always pad string parameters
> with spaces by hand?
The F95 standard says that all of the elements in the array constructor
have to be of the same length (type and type parameters). F2003 allows
them to be different lengths and you can specify the target length with
an optional type keyword, such as
[character(5)::"tan","atan2","atan","sin","asin"]
Current ifort supports the mixed lengths, padding as needed to the
longest length. The type specification is not supported in ifort 10.1.
By the way, the use of square brackets is also not standard in F95, but
is in F03. If you want to be F95 standard conforming, pad the values
and use (/ /) delimiters.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Richard Maine
> character(len=5), parameter :: test(5) =
> ["tan","atan2","atan","sin","asin"]
> 1
> Error: Element in character array constructor at (1) has length 5
> instead of 3
> Still, this is a bug i think....
No, this is not a bug in g95. It is a bug in your code. This was
essentially the first interpretation question I ever asked about f90. I
read the standard and had trouble imagining that things would really
this way because it was so much of a PITA - shades of Pascal - so I
posted a question about it here. This was before I had ever been to a
standards meeting, much less been a member. Then when I went to my first
X3J3 meeting, I found that my question from the newsgroup had been
brought to X3J3 as a formal interpretation question.
It turns out that there are more complications to the question than I
had imagined. The complications arise in cases where it is non-trivial
for the compiler to tell up front to tell what the character lengths
are. Yes, that can happen. It usually involves things like function
calls where the function returns a string of computed length. Implied DO
loops that can possibly be zero-trip ones make things worse. Trust me
that it can get really, really messy - messier than I'd have ever
believed. Henry Zongaro had an incredible ability to find the obscure
cases that broke every rule that anyone proposed to "fix" things. The
messy cases mostly weren't things that "sane" users would actually do,
but they were a big deal for compiler writers who are supposed to make
the compiler work even for the "insane" users if the standard says it is
supposed to work.
It was in 1991 that I posed this question. Though it was formally
answered a few years later (yes, it took a few years because of all the
proposed answers that Henry's examples shot down), it isn't until f2003
that the PITA is "reasonably" fixed in my opinion. I was glad to read
here just a day or two ago that Gfortran actually implements that f2003
feature now. I haven't checked for it in g95; suppose I ought to.
In f2003, you can explicitly specify the type and type parameters for an
array constructor. This has several effects, one of which is that the
elements in the constructor can have diferent types and type parameters
as long as the needed intrinsic conversion exists.
Thus your example can be written in f2003 as
character(len=5), parameter :: test(5) = &
[character(len=5) :: "tan","atan2","atan","sin","asin"]
Although that looks a bit redundant, it does the job. The apparent
redundancy is because the array constructor does not pick up its type
and type parameters from context. See many, many questions about the
more general case of that principle (most often relating to precision of
reals).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> wim <wim.van....@gmail.com> wrote:
>> character(len=5), parameter :: test(5) =
>>["tan","atan2","atan","sin","asin"]
>> 1
>>Error: Element in character array constructor at (1) has length 5
>>instead of 3
> No, this is not a bug in g95. It is a bug in your code. This was
> essentially the first interpretation question I ever asked about f90. I
> read the standard and had trouble imagining that things would really
> this way because it was so much of a PITA - shades of Pascal - so I
> posted a question about it here.
(snip)
Is this another side effect of the rule that the right side
of an assignment (even though it isn't an assignment) doesn't
depend on the type on the left?
My first thought is that it should work for a DATA statement,
but now I am not even sure about that.
(snip)
> In f2003, you can explicitly specify the type and type parameters for an
> array constructor. This has several effects, one of which is that the
> elements in the constructor can have diferent types and type parameters
> as long as the needed intrinsic conversion exists.
> Thus your example can be written in f2003 as
> character(len=5), parameter :: test(5) = &
> [character(len=5) :: "tan","atan2","atan","sin","asin"]
> Although that looks a bit redundant, it does the job. The apparent
> redundancy is because the array constructor does not pick up its type
> and type parameters from context. See many, many questions about the
> more general case of that principle (most often relating to precision of
> reals).
One might think that PARAMETER was different, but it
seems that it isn't.
-- glen
wim
To make it compile, I padded the shorter elements in the array.
Now it compiles with g95, but upon execution, I get a segfault in
libc,
apparently, memcpy doesn't like my code...
Greetings,
Wim
Richard Maine
> My first thought is that it should work for a DATA statement,
> but now I am not even sure about that.
Depends what your referent is for "it". If you are referring to an array
constructor whose elements have different character lengths, then the
answer is twofold
1. Such array constructors are not allowed in the first place. Period.
Context is irrelevant.
2. Data statement values are required to be scalar anyway, so they can't
be array constructors, regardless of whether the array constructor is
valid or not.
If you are talking about character values in data statements having
different character length, then
1. There is no relationship among the different values in a data
statement, so there is no particular restriction on the
non-relationship. Each value is related only to its corresponding
data-statement-object.
2. Intrinsic conversion is allowed, so yes, that allows the character
lengths in the values to be diferent from the character length of the
data-statement object. That's also true of the other syntax of
initialization, by the way. The restriction in question relates only to
array constructors, independent of context. The array constructor
doesn't have to agree in character length with the variable being
initialized; it just has to be a valid array constructor in the first
place, with *SOME* well-defined length.
> One might think that PARAMETER was different, but it
> seems that it isn't.
One wouldn't think that if one realized that an array constructor is an
array constructor and is independent of context, like pretty much
everything else in expressions. *SURELY* you are aware of that kind of
issue in regards to precision; in fact, it is practically the same
issue, insomuch as kind and length are both type parameters.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>My first thought is that it should work for a DATA statement,
>>but now I am not even sure about that.
> Depends what your referent is for "it". If you are referring to an array
> constructor whose elements have different character lengths, then the
> answer is twofold
> 1. Such array constructors are not allowed in the first place. Period.
> Context is irrelevant.
> 2. Data statement values are required to be scalar anyway, so they can't
> be array constructors, regardless of whether the array constructor is
> valid or not.
Yes, but a DATA statement can initialize an array. As you say, I
look at the implementation too early. In any case, the actual
data has to be stored somewhere.
> If you are talking about character values in data statements having
> different character length, then
> 1. There is no relationship among the different values in a data
> statement, so there is no particular restriction on the
> non-relationship. Each value is related only to its corresponding
> data-statement-object.
As one might also think for an array PARAMETER.
> 2. Intrinsic conversion is allowed, so yes, that allows the character
> lengths in the values to be diferent from the character length of the
> data-statement object. That's also true of the other syntax of
> initialization, by the way. The restriction in question relates only to
> array constructors, independent of context. The array constructor
> doesn't have to agree in character length with the variable being
> initialized; it just has to be a valid array constructor in the first
> place, with *SOME* well-defined length.
>>One might think that PARAMETER was different, but it
>>seems that it isn't.
> One wouldn't think that if one realized that an array constructor is an
> array constructor and is independent of context, like pretty much
> everything else in expressions. *SURELY* you are aware of that kind of
> issue in regards to precision; in fact, it is practically the same
> issue, insomuch as kind and length are both type parameters.
DEC had PARAMETER in some of the Fortran 66 compilers many years
ago. It was a great improvement because it allowed, for example,
symbolic names for array dimensions. Variables weren't allowed,
even constant expressions weren't, but PARAMETERs were.
(And PARAMETERS were even allowed constant expressions.)
One result is that I tend to think of PARAMETER as
different from assignment. The problem of precision of REAL
variables and PARAMETER was discussed not so long ago.
Mixed mode expressions are one of the conveniences of Fortran,
not having to do explicit conversions. Good or bad, that
extends to single precision constants assigned to double
precision variables. But PARAMETER is different.
At least I still think of PARAMETER as a named constant.
Unlike the case of mixed mode expressions, there doesn't
seem to be as good a reason to allow (at least without
a warning) PARAMETERs with the wrong type.
Even so, assigning the type (and length) of an array
constructor on the first element does seem strange.
-- glen
John Harper
Richard Maine <nos...@see.signature> wrote:
>... Gfortran actually implements that f2003
>feature now. I haven't checked for it in g95; suppose I ought to.
>
> character(len=5), parameter :: test(5) = &
> [character(len=5) :: "tan","atan2","atan","sin","asin"]
That's OK in g95.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
robin
>No, this is not a bug in g95. It is a bug in your code. This was
>essentially the first interpretation question I ever asked about f90. I
>read the standard and had trouble imagining that things would really
>this way because it was so much of a PITA - shades of Pascal - so I
>posted a question about it here. This was before I had ever been to a
>standards meeting, much less been a member. Then when I went to my first
>X3J3 meeting, I found that my question from the newsgroup had been
>brought to X3J3 as a formal interpretation question.
>
>It turns out that there are more complications to the question than I
>had imagined. The complications arise in cases where it is non-trivial
>for the compiler to tell up front to tell what the character lengths
>are.
Is it really?
Other compilers have implemented initialization of strings having
unequal lengths from the 1960s, notably, PL/I (1966) and XPL (c. 1966).
It's trivial for the compiler to count the number of characters
in each constant as it scans them, and to determnine the maximum length
of all those strings.
Compilers for both languages deal with null strings.
robin
>Richard Maine wrote:
>> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>>>My first thought is that it should work for a DATA statement,
>>>but now I am not even sure about that.
>
>> Depends what your referent is for "it". If you are referring to an array
>> constructor whose elements have different character lengths, then the
>> answer is twofold
>
>> 1. Such array constructors are not allowed in the first place. Period.
>> Context is irrelevant.
>
>> 2. Data statement values are required to be scalar anyway, so they can't
>> be array constructors, regardless of whether the array constructor is
>> valid or not.
>
>Yes, but a DATA statement can initialize an array. As you say, I
>look at the implementation too early. In any case, the actual
>data has to be stored somewhere.
That's irrelevant to constructors.
>DEC had PARAMETER in some of the Fortran 66 compilers many years
>ago. It was a great improvement because it allowed, for example,
>symbolic names for array dimensions. Variables weren't allowed,
>even constant expressions weren't, but PARAMETERs were.
>(And PARAMETERS were even allowed constant expressions.)
That's completely irrelevant to constructors.