Re: Formatting a real with an I edit descriptor.

jfh <john.harper@xxxxxxxxx> wrote:

On Apr 23, 8:55 am, Ron Shepard <ron-shep...@xxxxxxxxxxxxxxxxxx>
wrote:
You
can do this in a standard way with the transfer() intrinsic. You can
also do it in a different nonstandard (but also common) way using the
equivalence statement. (Well I think this is nonstandard. I've done it
so many times assuming it was nonstandard, I don't know for sure.)

real f
integer if
equivalence (f,if)
f = 10.0
write(*,'(i20,3x,f20.2)') if,f

$.02 -Ron Shepard

OK - I'll ask the dumb question: what's nonstandard about Ron's code?
Equivalencing default real and default integer is explicitly allowed
in both the f95 and f2003 standards section 5.5.1, and I see no
failure to obey the 9 constraints in f95 or the 11 constraints in
f2003.

You are focussing on syntax, which is in many ways a small part of the
language. Look at definition status. I'm not going to bother to track
down the exact citations (but it shoudn't be hard to do so).

The syntax is fine, but when you assign a value to f, that makes "if"
undefined. There's a specification of that somewhere - probably in the
long list of events that cause variables to become undefined. Aw heck, I
said I wasn't going to track it down, but let's take a look.... Well
that one was easy as it is item number 1 in the list (in 16.5.6).

Put that together with a broad condition somewhere that says a variable
must be defined when it is referenced, plus the definition of
"referenced" which wil match the appearance in an output list. Those
bits I'm not going to bother to track down, but they are there.

Odds are high that this will work, but it is nonstandard. I don't recall
whether this kind of case is caught by any of the compilers that try to
detect the usage of undefined variables. You can't detect this one by
just using a special bit pattern because there are two variables that
share the same address (at least with the usual implementation), yet one
is defined and the other isn't.

The TRANSFER case is pretty darn close to the same thing, but there is a
niggly distinction in what the standard says about it. The standard says
that the results of the TRANSFER case are "processor dependent" instead
of "undefined". For about 99% of all purposes, you can't tell the
practical difference between those two conditions; a compiler could give
any result and meet both conditions equally well. But in theory, there
are some classes of behavior that are technically allowed for the
"undefined" case that wouldn't be allowed for the "pricessor dependent"
case. I have never seen these behaviors actually happen.

1. The compiler could detect the undefined case as an error and report
it as such. It is at least vaguely possible that some compiler might do
this. Many people would consider a compiler that could catch that to be
doing a very good job of helping debug code.

2. The usual bit about any random thing, including WWIII resulting from
nonstandard code. Showing up as random bugs (even without the WWIII
thing) just doesn't seem plausible for this kind of thing, though. The
standard allows it, but I can't imagine a real compiler doing that.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Initial padding for common block
    ... Also nonstandard. ... Standard unformatted I/O is *VERY* picky about types. ... The compiler is permitted to ... necessarily mean that anything will actually diagnose it - it ...
    (comp.lang.fortran)
  • Re: reporting default integer size
    ... < intended result is nonstandard." ... < I am aware that the standard does not specify what the result of the ... I talk about the standard conformance of the compiler - not of the ...
    (comp.lang.fortran)
  • Re: Fortran
    ... > The F66 standard says something like the value is undefined. ... If something is nonstandard, ... variables is nonstandard and indeed won't compile at all with some ... If something gives a processor-dependent result, ...
    (comp.lang.fortran)
  • Re: Formatting a real with an I edit descriptor.
    ... Others have commented about what "correct" might mean with a nonstandard ... and modintrinsics, they all do similar but different things. ... can do this in a standard way with the transferintrinsic. ... equivalence statement. ...
    (comp.lang.fortran)
  • Re: Non-standard arithmetic
    ... is that the usual rules of arithmetic apply to the nonstandard ... the standard elements and nonstandard (infinite) elements. ... The intended interpretation of the Peano Axioms is that the variables ...
    (sci.logic)
Loading