Prev: Simple hack to get $600 to your home.
Next: type bound procedure
From: dpb on 16 Jun 2010 23:27
steve wrote:
> On Jun 16, 7:50 pm, dpb <n...(a)non.net> wrote:
>> A Watcher wrote:
>>> At work we have a large legacy application with thousands of lines of
>>> code and hundreds of subroutines. I've worked on it for years and now
>>> they've assigned a jr programmer to do maintenance work as I've already
>>> retired twice. The new person has a computer science degree but has
>>> never seen fortran before.
>>> She introduced a coding error that I had a real hard time tracing down.
>>> She set x=0 where x was an allocatable array that hadn't been allocated
>>> yet. What happened was some other data got set to zero, but the program
>>> didn't blow up until the zero data caused problems.
>>> Should that have been caught at run time? I have turned on all of the
>>> runtime error checking that I could find. The program runs on an
>>> elderly RS6000 AIX system and uses the IBM xlf compiler.
>> It is (of course, and as I'm sure you know and isn't the question)
>> illegal to refer to the array until and unless it has been allocated.
>> But, afaik, it's not required to be diagnosed.
>
> xlf is a F2003 compiler. Does 7.4.1.3 apply?
>
> If variable is an allocated allocatable variable, it is
> deallocated if expr is an array of different shape or any
> of the corresponding length type parameter values of
> variable and expr differ. If variable is or becomes an
> unallocated allocatable variable, then it is allocated with
> each deferred type parameter equal to the corresponding type
> parameters of expr, with the shape of expr, and with each
> lower bound equal to the corresponding element of LBOUND(expr).
>
> In other words, allocate on assignment.

Hmmmm...forgot about that; don't have a clue about F2003 features.

The "elderly" got me not even thinking about could be newer compiler
than hardware.

So, "I dunno"...

--
From: glen herrmannsfeldt on 17 Jun 2010 00:18
steve <kargls(a)comcast.net> wrote:
(snip)

> xlf is a F2003 compiler. Does 7.4.1.3 apply?

> If variable is an allocated allocatable variable, it is
> deallocated if expr is an array of different shape or any
> of the corresponding length type parameter values of
> variable and expr differ. If variable is or becomes an
> unallocated allocatable variable, then it is allocated with
> each deferred type parameter equal to the corresponding type
> parameters of expr, with the shape of expr, and with each
> lower bound equal to the corresponding element of LBOUND(expr).

> In other words, allocate on assignment.

What does allocate on assignment do with a scalar assignment?
As far as I know, a scalar is not the same as a one element array.

On the other hand, the OP was lucky (or unlucky, as the case may be)
that the uninitialized bounds weren't huge and wipe out much of
the program's memory.

-- glen
From: Richard Maine on 17 Jun 2010 01:43
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> What does allocate on assignment do with a scalar assignment?

Nothing.... well nothing in the case of assigning a scalar to an array
anyway. That requires that the array be previously allocated for the
presumably obvious reason.

(Scalar assignment can trigger allocation, but that's only in the case
of a scalar left-hand side. I wouldn't mention it except that your
terminology is vague enough to include that case and I didn't want to
incorrectly say that assigning a scalar can never trigger allocation.
Yes, scalars can be allocatable in f2003.)

> As far as I know, a scalar is not the same as a one element array.

Correct.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Richard Maine on 17 Jun 2010 01:53
dpb <none(a)non.net> wrote:

> It is (of course, and as I'm sure you know and isn't the question)
> illegal to refer to the array until and unless it has been allocated.
> But, afaik, it's not required to be diagnosed.

Almost nothing is required to be diagnosed at run time. That's pretty
much a universal principle in the standard (even though it doesn't use
terms like "run time", the concepts are there.) There is probably an
exception or two somewhere, but I have trouble thinking of them
off-hand. This certainly isn't one of them.

On the other hand, I'd certainly think it a reasonable quality of
implementation expectation. It is, after all, an awful lot like
referencing a null pointer, and catching errors like that is a common
quality of implementation issue. In fact, problems like that with
allocatables are easier for a compiler to catch than some related
problems with pointers. That's because allocatable always have a known
status. There is not the possibility of the allocation status being
undefined. It is either allocated or not and that is always an
inquirable property. There should never be the possibility that an
allocatable looks valid, but turns out to point out some memory that it
doesn't "own."

As noted, the compiler is not required to diagnose things like that, or
even to have the capability to do so in a debug mode. But I see no good
reason why a compiler shouldn't have that capability.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 17 Jun 2010 02:11
Craig Powers <craig.powers(a)invalid.invalid> wrote:
(snip)

>> She introduced a coding error that I had a real hard time tracing down.
>> She set x=0 where x was an allocatable array that hadn't been allocated
>> yet. What happened was some other data got set to zero, but the program
>> didn't blow up until the zero data caused problems.

>> Should that have been caught at run time? I have turned on all of the
>> runtime error checking that I could find. The program runs on an
>> elderly RS6000 AIX system and uses the IBM xlf compiler.

> It depends what you mean by "should".

> From my point of view, quality run-time bounds-checking would also pick
> an error like this up, but it does seem like something that is very much
> a QoI issue.

In Fortran 2003 arrays are allowed to have size zero. It might have
been nicer if the bounds had been initialized to zero, such that
the assignment didn't write over something else.

Otherwise, scalar to array assignment should never cause
a bounds violation.

-- glen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Simple hack to get $600 to your home.
Next: type bound procedure