Assignment of undefined variables

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 ]

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
>

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 ]

Dick Hendrickson <dick.hendrickson@att.net> writes:
 

> 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

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

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

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

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

> 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

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 compil
er
> 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