I am trying to print out True and False instead of T and F. I would
like to use a logical as an array index, but can't in F90. I have
tried the following, and it works on Intel v10, but will it always
work, ie. is the integer value of .true. always -1? (I don't want to
get an array bounds error if .true. /= -1)

program fred

integer iii
logical truth
CHARACTER(LEN=5), DIMENSION(-1:0), PARAMETER :: e_truth = (/
'False','True ' /)

truth = .true.
iii = truth
write(6,*) iii
write(6,*) e_truth(iii)

truth = .false.
iii = truth
write(6,*) iii
write(6,*) e_truth(iii)

end

Sorry got the enum the wrong way around, also simplified using
equivalance:

program fred

integer iii
logical truth
equivalence (iii,truth)
CHARACTER(LEN=5), DIMENSION(-1:0), PARAMETER :: e_truth = (/ 'True
','False' /)

truth = .true.
write(6,*) iii, e_truth(iii)

truth = .false.
write(6,*) iii, e_truth(iii)

end

ferrad wrote:

...sample code using internal representation of LOGICAL elided...

The short answer is "NO", you can't count on this for any other compiler.

There was an extensive thread just recently on the "erroneousnous" of
any code that relies on anything about the internal representation of
.TRUE. or .FALSE.

The only Standard-conforming way to output the desired values would be
something similar or logically equivalent to

if(logical) then
write(*,*) 'True'
else
write(*,*) 'False'
endif

As the other thread noted multiple times, any time one assigns or looks
at a LOGICAL using casts or other mechanisms than assignment or LOGICAL
operations all bets are off.

On Jul 10, 10:32 am, ferrad hotmail.com> wrote:

"dpb" non.net> wrote in message news:g557lj$ho$1@aioe.org...

That's funny, I thought that that thread was about a loophole in the
standard that permitted compilers to define 1 as .TRUE., 0 as .FALSE.
and anything else as undefined with unpredictable behavior, just...

James Van Buskirk wrote:

...

The upshot (at least as I understood it) was that all the efforts to
demonstrate the problem relied on a non-standard manipulation of or
attempt to ascertain the internal state of a LOGICAL outside
Standard-defined operations. If there were somewhere in the thread that
didn't occur, I didn't see it (or at least didn't recognize it).

--

James Van Buskirk comcast.net> wrote:

"Loophole" seems an odd term for it. To me, that term implies an
oversight or unintended effect. From the wikioedia definition "A
loophole in a law often contravenes the intent of the law without
technically breaking it."

While you have made it abundantly clear that you don't like the Fortran
rule in question, it isn't exactly a subtle or unintended effect. It was
deliberate and explicit, with the overt intent of allowing different
compilers the freedom to use different implementations to facilitate
efficiency. Since the rule was explicitly for the purpose of allowing
compiler freedom, it doesn't contravene the intent of the rule for
compilers to use that freedom.

"Loophole" is not a synonym for "something I dislike."

"dpb" non.net> wrote in message news:g55g1n$11h$1@aioe.org...

I guess the thing to do is to yell the loudest and the most, for only
in that way are ones views to be considered the conclusion of the
thread. I find it quite tedious when more than one person attempts
to preempt the discussion in this fashion, so I will have to content
myself with being a rather more staid outsider.

The message was

http://groups.google.com/group/comp.lang.fortran/msg/f836508b0b1bf90c

James Van Buskirk wrote:
..

It was simply what I drew from it (as noted)...

--

James Van Buskirk wrote: