Home > Archive > Fortran > December 2004 > Assignment of undefined variables
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Assignment of undefined variables
|
|
| Rich Townsend 2004-12-15, 3:59 pm |
| Hi all --
Consider the following snippet of code:
real :: a
real :: b
b = a
What does the standard say about such situations, where a variable is
assigned a value from another, undefined variable? Does this merely mean
that b becomes undefined (or, in this case, remains undefined)? Or does
the whole behaviour of the program become undefined, and Likely to Start
WIII?
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Dick Hendrickson 2004-12-15, 3:59 pm |
|
Rich Townsend wrote:
> Hi all --
>
> Consider the following snippet of code:
>
> real :: a
> real :: b
> b = a
>
> What does the standard say about such situations, where a variable is
> assigned a value from another, undefined variable? Does this merely mean
> that b becomes undefined (or, in this case, remains undefined)? Or does
> the whole behaviour of the program become undefined, and Likely to Start
> WIII?
>
In this snippet, it's WWIII :(. In F95, the first paragraph
of section 6 "A reference [that requires a value, like use
of "a" above] is permitted only if the data object is
defined." So, your program is non-standard.
For what it's worth, you could get around this by making
a or b be a user defined type thing and provide your own
assignment subroutine. That allows you to leave b undefined
after the assingment statement. (Lord knows why you'd
really want to do this, but you can!).
Dick Hendrickson
> cheers,
>
> Rich
>
| |
| Rich Townsend 2004-12-15, 3:59 pm |
| Dick Hendrickson wrote:
>
>
> Rich Townsend wrote:
>
> In this snippet, it's WWIII :(. In F95, the first paragraph
> of section 6 "A reference [that requires a value, like use
> of "a" above] is permitted only if the data object is
> defined." So, your program is non-standard.
>
> For what it's worth, you could get around this by making
> a or b be a user defined type thing and provide your own
> assignment subroutine. That allows you to leave b undefined
> after the assingment statement. (Lord knows why you'd
> really want to do this, but you can!).
Thanks for the info. To provide some background context for my weird
question, I was thinking about assingment of partially-defined arrays.
Suppose I have
real, dimension(5) :: a,b
a(1:3) = (/1.,2.,3./)
b = a
....with the intention that b(4) and b(5) are defined later in the
program. I was wondering whether such a construct is OK, but from what
you say, the ICBMs are in the air...
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Richard E Maine 2004-12-15, 3:59 pm |
| Dick Hendrickson <dick.hendrickson@att.net> writes:
[color=darkred]
> In this snippet, it's WWIII :(.
And, though I haven't noticed WWIII yet (I'd glance outside
to check, but no windows in this office :-()), there have
been and are today implementations where this will do "bad"
things.
I don't recall the details for sure, but some implementations
might possibly throw a fit if the undefined variable happened
to have an "unfortunate" bit pattern (like an IEEE signaling
NaN, or perhaps the old CDC indefinite).
And there exist implementations (Salford comes to mind as one),
that will detect the undefined reference and XXXXX about it (at
least with appropriate debugging modes turned on).
Strangely (the inconsistency has been commented on), the
comparable situation for pointer assignment has a different answer.
In
p => q
if p and q are pointers and the pointer association status of q is
undefined, then the code is still legal and the pointer asociation
status of p becomes undefined.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2004-12-15, 3:59 pm |
|
Rich Townsend wrote:
(snip)
> Thanks for the info. To provide some background context for my weird
> question, I was thinking about assingment of partially-defined arrays.
> Suppose I have
> real, dimension(5) :: a,b
> a(1:3) = (/1.,2.,3./)
> b = a
> ...with the intention that b(4) and b(5) are defined later in the
> program. I was wondering whether such a construct is OK, but from what
> you say, the ICBMs are in the air...
For floating point you are reasonably likely to have trap
representations, such as signalling NaN in IEEE. I believe that
assigning a signaling NaN can trigger the interrupt, though many
will do the assignment without using floating point operations.
If ordinary assignment of signaling NaN doesn't trigger an interrupt
precision conversion might. For twos complement integers, which
normally use all bit patterns, you might be safe.
-- glen
| |
| glen herrmannsfeldt 2004-12-15, 3:59 pm |
|
Richard E Maine wrote:
(snip)
> Strangely (the inconsistency has been commented on), the
> comparable situation for pointer assignment has a different answer.
> In
> p => q
> if p and q are pointers and the pointer association status of q is
> undefined, then the code is still legal and the pointer asociation
> status of p becomes undefined.
One case where you could expect problems, so I would hope
that undefined pointers are appropriately initialized.
On protected mode x86, and likely other processors, arbitrary
pointers can't be loaded. Well, segment selectors must be
valid, or be the null selector, 0.
Though in most cases assignment can be done by copying the
bits instead of through a segment register.
-- glen
| |
| Richard E Maine 2004-12-15, 8:57 pm |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> One case where you could expect problems, so I would hope
> that undefined pointers are appropriately initialized.
Your expectation is probably unrealistic. If anything at all
about them could be guaranteed, then there wouldn't be much
need for the undefined status.
Undefined pointers (well, technically, pointers with an
association status of undefined, which isn't quite the same
thing - the pointer being undefined would refer to the
"data" of the pointer instead of to the association status)
are...undefined. They are quite likely to have random garbage
bits in them.
> On protected mode x86, and likely other processors, arbitrary
> pointers can't be loaded. Well, segment selectors must be
> valid, or be the null selector, 0.
>
> Though in most cases assignment can be done by copying the
> bits instead of through a segment register.
That's what I'd expect. Sounds like that's what a compiler better
do if it expects to be standard-conforming. There *IS* code
that depends on this stuff working even for pointers with
undefined association status. A bit unfortunate that, but
add something about cats and bags.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| David Frank 2004-12-16, 3:57 am |
|
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:cpq3qo$i16$1@gnus01.u.washington.edu...
>
>
> Richard E Maine wrote:
>
> (snip)
>
>
>
>
> One case where you could expect problems, so I would hope
> that undefined pointers are appropriately initialized.
>
> On protected mode x86, and likely other processors, arbitrary
> pointers can't be loaded. Well, segment selectors must be
> valid, or be the null selector, 0.
>
> Though in most cases assignment can be done by copying the
> bits instead of through a segment register.
>
> -- glen
>
ALL Fortran F9x compilers for Intel x86 use flat addressing.
Setting segment registers as part of 16-bit extended addressing is not
involved.
Your continued talking about segment registers points to your use
of some obsolete 16-bit mode Windows 3.1 based F77 compiler
that Windows-9X/XP possibly can still run. How about updating your compiler
and start talking about modern Fortran.
| |
| Jan Vorbrüggen 2004-12-16, 8:58 am |
| > Thanks for the info. To provide some background context for my weird
> question, I was thinking about assingment of partially-defined arrays.
[snip example]
> ....with the intention that b(4) and b(5) are defined later in the
> program. I was wondering whether such a construct is OK
I believe it is. As I understand it, it "merely" is the programmer's
responsibility to properly keep track of undefined variables and pointers,
and to not write code that will read them while they are undefined. And
I would assume that the status of being defined or not is associated with
any item that can be individually read or written, e.g., each array element
or derived-type component, not the array or derived type as a whole. Other-
wise, such partial initialization as you showed would not make much sense.
Jan
| |
| glen herrmannsfeldt 2004-12-16, 4:05 pm |
| David Frank wrote:
(snip)
> ALL Fortran F9x compilers for Intel x86 use flat addressing.
> Setting segment registers as part of 16-bit extended addressing is not
> involved.
> Your continued talking about segment registers points to your use
> of some obsolete 16-bit mode Windows 3.1 based F77 compiler
> that Windows-9X/XP possibly can still run. How about updating your compiler
> and start talking about modern Fortran.
The standard applies to all compilers and all machines.
You are not allowed to pick and choose which compilers
follow the standard and which do not.
-- glen
| |
| Richard E Maine 2004-12-16, 4:06 pm |
| Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:
> [snip example]
>
> I believe it is. As I understand it, it "merely" is the programmer's
> responsibility to properly keep track of undefined variables and pointers,
> and to not write code that will read them while they are undefined.
Something  here. I'd agree with that description, except that
the code in question *DOES* "read" them when they are undefined. (The
precise term used in the standard is "reference" instead of "read", but
that's basically what it means).
> And
> I would assume that the status of being defined or not is associated with
> any item that can be individually read or written, e.g., each array element
> or derived-type component, not the array or derived type as a whole. Other-
> wise, such partial initialization as you showed would not make much sense.
I'm afraid you are wrong here. The standard is explicit about this
question. An array is defined if and only if all of its elements are
defined. Somewhere in c14 of f95, which is c16 of f2003. I don't feel
like taking the time to look it up right now, but it is pretty
explicit. There have been some related "issues", but they are on far
more subtle points that this and related to whether a derived type
object is defined. The array case is straightforward. Things like
pointer and allocatable components for derived types require extra
words, as does the distinction between intrinsic and defined
assignment.
The partial initialization makes fine sense. It just isn't sufficient
to define the whole array, so you can't do whole array references
(like assignment) until the rest of the elements are defined. You
can, however, reference the individual defined elements.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Jan Vorbrüggen 2004-12-17, 8:57 am |
| > Something here. I'd agree with that description, except that
> the code in question *DOES* "read" them when they are undefined.
Ah, I overlooked that. Then of course it is not standard-conforming.
> The partial initialization makes fine sense. It just isn't sufficient
> to define the whole array, so you can't do whole array references
> (like assignment) until the rest of the elements are defined. You
> can, however, reference the individual defined elements.
Sure, that's what I meant. So you could say that the definedness of any
compount object (array, array slice, derived type variable) is the AND
of the definedness of its constituent components for which definedness
is defined 8-). Can we agree on that?
Jan
| |
| Richard E Maine 2004-12-17, 3:58 pm |
| Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:
> Sure, that's what I meant. So you could say that the definedness of any
> compount object (array, array slice, derived type variable) is the AND
> of the definedness of its constituent components for which definedness
> is defined 8-). Can we agree on that?
Yes. Not quite the way I'd usually express it, but I think it is
correct (given suitable definitions of a few of the terms. :-))
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
|
|
|
|
|