Prev: Simple hack to get $600 to your home.
Next: type bound procedure
From: Richard Maine on 17 Jun 2010 03:45
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>
> 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.

I disagree. That would initialize them to an allocated state with a
particular choice of size. You happened to choose zero. Doesn't seem to
me like that is much different from expecting all variables to be
initialized to a particular choice of value - say zero. That sounds to
me like a strange and inconsistent hack just in order to catch something
that:

1. Could just as easily be caught anyway as an error. As noted in my
other post, it isn't as though it would be particularly difficult to
catch the error.

2. Doesn't actually fix any error, but just changes the sympotoms. In
fact, you just changed what is now an error that at least could be
detected by a compiler into code that is technically valid and thus
cannot be diagnosed by the compiler as an error, but still is probably a
bug in the code. It is just a bug that became harder to find.

3. And doesn't do anything to address otherwise simillar cases such as
assignment to an array pointer that is not associated.

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

I'm not sure what you mean by this "should", but I disagree with what it
seems to be saying. Giving an error diagnosis when the code is buggy is
a *GOOD* thing.

--
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 04:23
Richard Maine <nospam(a)see.signature> wrote:
> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

>> 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.

> I disagree. That would initialize them to an allocated state with a
> particular choice of size. You happened to choose zero.

No, I meant unallocated state with size zero.

That is, ALLOCATED() returns .FALSE., but UBOUND() is less than
LBOUND() such that loops through the array don't store (or fetch)
anything. (Either implied loops in array expressions, or explicit
DO loops using lbound and ubound.

> Doesn't seem to
> me like that is much different from expecting all variables to be
> initialized to a particular choice of value - say zero. That sounds to
> me like a strange and inconsistent hack just in order to catch something
> that:

How is it that arrays get the unallocated state? Isn't that
an initialization of the allocated state bit? Now, if they
also had the undefined state then I would agree.

> 1. Could just as easily be caught anyway as an error. As noted in my
> other post, it isn't as though it would be particularly difficult to
> catch the error.

It wouldn't. It wouldn't be that hard to catch any other access
to an undefined variable, either, but it requires extra work
on every access. (One could, for example, have a logical variable
coresponding to each actual variable indicating its undefined state.)
That test could easily be inside a deeply nested loop, or otherwise
be executed very many times.

Now, I forget how it is that they get the unallocated state instead
of the undefined state, but however the unallocated state is set,
could also set the size to zero. Such would normally be outside
any inner loops, and would normally not get executed very often.

> 2. Doesn't actually fix any error, but just changes the sympotoms. In
> fact, you just changed what is now an error that at least could be
> detected by a compiler into code that is technically valid and thus
> cannot be diagnosed by the compiler as an error, but still is probably a
> bug in the code. It is just a bug that became harder to find.

It seems that the OP was particularly unlucky. If random bits
were stored in a 32 bit length field, it could easily have written
over gigabytes of storage, but that didn't happen.

I presume it is still invalid to assign to an unallocate array
of length zero, and you can still detect it by testing for the
unallocated state. Setting the size to zero, though, means
that the compiler generate loops for array expressions will
not execute, without any extra tests or conditional branches.

> 3. And doesn't do anything to address otherwise simillar cases
> such as assignment to an array pointer that is not associated.

The bounds of an array pointer that is unassociated could also
be set to have a zero length at the same time that the unassociated
state is set. Pointers in the undefined state presumably also have
undefined bounds, so that doesn't change.

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

> I'm not sure what you mean by this "should", but I disagree with what it
> seems to be saying. Giving an error diagnosis when the code is buggy is
> a *GOOD* thing.

Consider the non-array-expression code:

do i=lbound(x,1),ubound(x,1)
x(i)=0
enddo

even with bounds checking on, it should not be necessary to do
bounds checking on the assignment to x. The loop can't go outside
the bounds of the array. For a more general such loop, the loop
values can be compared to the array bounds before executing the
loop, instead if inside the loop, speeding up the result.

-- glen

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

> Richard Maine <nospam(a)see.signature> wrote:
> > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>
> >> 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.
>
> > I disagree. That would initialize them to an allocated state with a
> > particular choice of size. You happened to choose zero.
>
> No, I meant unallocated state with size zero.

Oh. No wonder I didn't understand. Unallocated arrays don't have a size.
So what you are suggesting has more to do with introducing a concept of
being unalocated yet having a size than with initialization in
particular.

Speaking of which, if you are talking only about initialization, then
what would happen if the array became unallocated later, as with an
explicit deallocate statement? Seems to me that you would need to define
that unallocated arrays always have a size of zero in order to get the
apparently desired effect. Initialization isn't even related except
indirectly in that arrays are initialized to unallocated and this would
change the meaning of unallocated.

If that's what you are talking about, I wouldn't have expected the word
"initialization" to even come up in describing it, so I see why I was
thrown off by descrining it in terms of initialization. If that's not
what you are talking about, then I obviously still don't understand.

The whole thing still sounds like a hack to me, and I don't see the
purpose. Seems like you just made being unallocated act just like being
allocated with size zero, with the only difference being that it return
..false. from the allocated intrinsic. We already have the concept of
being allocated with size zero; that's one I have used fairly regularly
myself. I don't see the point of this other state. And I don't see how
it could be consistently defined without putting a bunch of special-case
hacks in multiple places in the standard to allow referencing an
unallocated array in some cases (and one would have to define those
cases).

Sounds sort of like declaring that it is ok to reference an undefined
variable as long as, say, you are doing something like multiplying it by
0 so that the result wouldn't really need the value.

And the end effect is to cover up bugs instead of getting them
diagnosed. I don't see new useful functionality that isn't already
achieved by the existing functionality of having zero-sized allocated
allocatables. All I see is making it harder to catch bugs.

> It wouldn't be that hard to catch any other access
> to an undefined variable, either, but it requires extra work
> on every access.

No, that is not the case. It would be a *LOT* more work than that to
catch every case of undefined variables. I'm tempted to say it is
actually impossible, but that might be stretching a bit too far. It
certainly isn't anywhere near that easy. Catching some cases is easy.
Catching all of them is not. Allocation status is inquirable about. The
compiler is essentally required to trackit and, by design,that is
practical. Being undefined is not inquirable about... and there is a
reason.

> (One could, for example, have a logical variable
> coresponding to each actual variable indicating its undefined state.)

That says nothing about how to get this logical set, which is the hard
part, considering that a variable can become undefined because of
indirectly related happenings in parts of the program where the variable
isn't even in scope. (I think you'd also need to recheck the definition
of "variable" which changed as of f90; the term "each variable" implies
that the set of variables is practical to enumerate.)

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: cessenat on 17 Jun 2010 12:37
On Jun 17, 4:26 am, A Watcher <stocks...(a)earthlink.net> wrote:
> 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.

I don't know with xlf, but ifort -check pointers issues the
following RT message:
<<
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
variable X when it is not allocated
Image PC Routine Line
Source
a.out 0000000000404AE2 Unknown Unknown
Unknown
a.out 000000000040349D MAIN__ 13
legacy.f90
>>
As well about the "allocate on assignment" topic, ifort requires -
assume realloc_lhs to actually perform the standard.
Sincerely,
Olivier.
From: glen herrmannsfeldt on 17 Jun 2010 15:12
cessenat <cessenat(a)gmail.com> wrote:
(snip)

> I don't know with xlf, but ifort -check pointers issues the
> following RT message:

> forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
> variable X when it is not allocated
(snip)

> As well about the "allocate on assignment" topic, ifort requires -
> assume realloc_lhs to actually perform the standard.

As it isn't standard until Fortran 2003, compilers not claiming
(or not set to) that standard wouldn't be expected to do it.

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