Prev: Simple hack to get $600 to your home.
Next: type bound procedure
From: glen herrmannsfeldt on 17 Jun 2010 15:38
Richard Maine <nospam(a)see.signature> wrote:
> 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.

Well, I didn't say that it should be added to the standard, but
may have implied that. (Which at this point means about 2013, and
appearing in compilers by 2023.) I wrote "would have been nice" which
could just be a quality of implementation issue. (As far as I know,
there are no "quality of implementation" suggestions in the standard.)

In the usual case, there is a descriptor containing the sizes and
the address of the allocated space, if any. It might also contain
an "allocated" indicator, or may use zero as the address for the
unallocated state. I could also imagine hardware that included
such a feature, but didn't allow access to the sizes in the
unallocated state. But note that I am not against any checking
that the system might do, but only that in the case that no
checking is done that "it might be nice" if the array had zero size.

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

I might be confused on this. Is it that pointers can have the
"uninitialized" state, but that allocatables can't?

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

With the recent discussion on initializing to zero, maybe I was
still considering that. Which term would you use?

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

You likely need the other state for programs that rely on the
unallocated state at startup. (That was my assumption, anyway.)

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

OK, lets try it this way. If you access an ordinary, unitialized,
variable you don't expect your computer to explode. The standard
doesn't say that, but you still expect it not to happen. Maybe
that is "quality of implementation."

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

As I said before, it seems that the OP was particularly unlucky.
The effect was small enough for the program to continue for a
while, such that it wasn't noticed. That seems to make diagnosing
harder.

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

As far as I know, the only reason that it isn't done is that it
is too slow. (And maybe also takes up too much memory.) Doing
the check on allocatable arrays on every access would also be
slow, though maybe not quite as bad, as there usually aren't as
many allocatables as not.

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

What happens to the allocation status in those cases?

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

Yes I didn't recheck the definition of variable.

-- glen

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

> Well, I didn't say that it should be added to the standard, but
> may have implied that. (Which at this point means about 2013, and
> appearing in compilers by 2023.) I wrote "would have been nice" which
> could just be a quality of implementation issue. (As far as I know,
> there are no "quality of implementation" suggestions in the standard.)

Oh. I'd think a much better quality of implementation would be to
diagnose the error.

Yes, by the way, there are some quality of implementation suggestions in
the standard. But not many of them, and they don't have much effect. I
recall one that I made fun of when it was put in because of how silly it
seemed to say it in the standard. There was a suggestion that the vendor
ought to document stuff (I forget what stuff in particular, but it
doesn't make much difference.) Since that was already a "motherhood"
suggestion with no substantative content, I commented that we might as
well also suggest that the documentation be good. My comment wasn't
accepted. :-)

> But note that I am not against any checking
> that the system might do, but only that in the case that no
> checking is done that "it might be nice" if the array had zero size.

I'm of the opposite opinion - that it would be best to do things likely
to expose the error rather than hide it. If one doesn't otherwise check,
maybe set the base address to something likely to generate a segfault if
nothing else. But it really is not hard to check. I think it pretty much
a bad idea to pay too much attention to what happens if you don't check
because that distracts from emphasizing to just do the darn check.

> I might be confused on this. Is it that pointers can have the
> "uninitialized" state, but that allocatables can't?

There is no such term as "uninitialized" in the standard. There is a
state of being undefined. That is related in that some things start out
undefined if they are not initialized, but the term is "undefined" - not
"uninitialized." The distinction is important because something can well
be initialized, but then later become undefined; happens all the time.

There is no such thing as an undefined allocation status. (There was in
f90, but that was a serious problem, which was fixed in f95). There is
such a thing as undefined pointer association status. That is a
critically important concept in pointers. People who don't understand it
almost invariably write buggy pointer code, sometimes by trying to use
the associated intrinsic for things it won't actually do.

Note as a not entirely irrelevant aside, that an allocated allocatable
variable can be undefined as well as any other variable. The allocation
status is separate from the variable definition property.

> > 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.
>
> With the recent discussion on initializing to zero, maybe I was
> still considering that. Which term would you use?

As I mentioned, it sounds to me like you are talking about unallocated
array variables.

> > It would be a *LOT* more work than that to
> > catch every case of undefined variables.
>
> As far as I know, the only reason that it isn't done is that it
> is too slow.

I don't believe it is doable by design. And I think you would find more
significant problems than just time and memory if you tried (not that
those problems would be trivial). Note that none of the compilers that
do undefined variable checking come particularly close to catching all
cases (but catching just the simple ones can certainly be useful).

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

>> Well, I didn't say that it should be added to the standard, but
>> may have implied that. (Which at this point means about 2013, and
>> appearing in compilers by 2023.) I wrote "would have been nice" which
>> could just be a quality of implementation issue. (As far as I know,
>> there are no "quality of implementation" suggestions in the standard.)

> Oh. I'd think a much better quality of implementation would be to
> diagnose the error.

I agree, but I think that is too slow in too many cases.

(snip about "quality of implementation in the standard.)

>> But note that I am not against any checking
>> that the system might do, but only that in the case that no
>> checking is done that "it might be nice" if the array had zero size.

> I'm of the opposite opinion - that it would be best to do things likely
> to expose the error rather than hide it. If one doesn't otherwise check,
> maybe set the base address to something likely to generate a segfault if
> nothing else. But it really is not hard to check. I think it pretty much
> a bad idea to pay too much attention to what happens if you don't check
> because that distracts from emphasizing to just do the darn check.

Too many systems make it hard to find the cause of a segfault,
but otherwise I would agree with that one.

>> I might be confused on this. Is it that pointers can have the
>> "uninitialized" state, but that allocatables can't?

> There is no such term as "uninitialized" in the standard. There is a
> state of being undefined. That is related in that some things start out
> undefined if they are not initialized, but the term is "undefined" - not
> "uninitialized." The distinction is important because something can well
> be initialized, but then later become undefined; happens all the time.

Yes "undefined state" was the one I was trying to remember the
name for, and which version it applied to allocatable arrays.

> There is no such thing as an undefined allocation status. (There was in
> f90, but that was a serious problem, which was fixed in f95).

(snip)
> Note as a not entirely irrelevant aside, that an allocated allocatable
> variable can be undefined as well as any other variable. The allocation
> status is separate from the variable definition property.

(snip)

> As I mentioned, it sounds to me like you are talking about
> unallocated array variables.

Well, yes. Arrays are often used in nested loops such that speed
is fairly important. Also, the ability to specify the size at
run time is especially useful. I suppose allocatable length
character variables will be similarly useful.

>> > It would be a *LOT* more work than that to
>> > catch every case of undefined variables.

>> As far as I know, the only reason that it isn't done is that it
>> is too slow.

> I don't believe it is doable by design. And I think you would find more
> significant problems than just time and memory if you tried (not that
> those problems would be trivial). Note that none of the compilers that
> do undefined variable checking come particularly close to catching all
> cases (but catching just the simple ones can certainly be useful).

Well, catching the ones that happen in your program is all that
is needed... If time and memory are not a problem, then a check
on every access should do it. Most reliable would be a separate
indicator for each. For floating point, you can use NaN as in-band
signaling, but that doesn't work so well for other types. Some that
I have known set a specific value and test for it, which fails if
that value ever occurs in the actual program.

Out of band signaling would require extra memory for each, which,
in the most obvious way that I see, doubles the size of every
value. (As I still haven't looked up the new definition for
variable, and, you would want to be able to check each array element.)

I suppose I don't know all the ways that something can become
undefined, nor how hard it would be to track down all those
ways and to set the undefined flag as needed.

For the case that I actually ran into not so long ago, when
ALLOCATE fails due to not having enough memory available it
seems that it just stored an invalid address and continued on.

In that case, I would have expected, and don't see any problem
with, generating a diagnostic message. The program, however,
segfaulted on the access to an array element.

-- glen
From: Ron Shepard on 17 Jun 2010 19:43
In article <hvcea8$gnr$1(a)speranza.aioe.org>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> In Fortran 2003 arrays are allowed to have size zero.

This is true for f90 and later.

$.02 -Ron Shepard
From: Richard Maine on 17 Jun 2010 19:48
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Richard Maine <nospam(a)see.signature> wrote:
> > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

Rich:

> >> > It would be a *LOT* more work than that to
> >> > catch every case of undefined variables.
>
> >> As far as I know, the only reason that it isn't done is that it
> >> is too slow.
>
> > I don't believe it is doable by design. And I think you would find more
> > significant problems than just time and memory if you tried (not that
> > those problems would be trivial).
>
> Well, catching the ones that happen in your program is all that
> is needed... If time and memory are not a problem, then a check
> on every access should do it.

That 100% misses my point. It is not a question of when you check. Yes,
that part is trivial (in principle). Just takes time and memory, as you
say.

> I suppose I don't know all the ways that something can become
> undefined, nor how hard it would be to track down all those
> ways and to set the undefined flag as needed.

Yes. Exactly. *THAT* is the part that is hard even in principle. (Plus,
if you managed to do it strictly, you'd get lots of complaints because
suddenly function side effects wouldn't work for one.)

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Simple hack to get $600 to your home.
Next: type bound procedure