Glenn Carver writes:
 > It seems a very common extension in f77 is for the INT() intrinsic function
 > to allow a logical as an argument. As far as I can tell this is not part of
 > the f77  standard but every f77 compiler I've used supports it.

I'd not really heard of this extension.  Frankly, I'm not even sure what
you would want INT() to do in this case.  All the other forms of INT
take numeric arguments and the desired result value is relatively
obvious (the main questions relate to rounding modes and the
result kind).

I can think of at least 3 completely different possible meanings of
INT() applied to logicals.

1. A mapping specified by the standard.  One value for true, and one
   other value for false.  I have no idea what particular values these
   would be.  Compiler internal representations of logicals certainly
   vary widely.  If you are counting on something like true being
   represented by 1 and false by 0, then I'm surprised you haven't run
   into lots of portability problems.  Its not a portable assumption.

   Of course, the standard would have been free to define some mapping
   for INT() that had no relation to the compiler representation of
   logical, but it didn't.

   If this is what you want, its pretty easy to write your own
   substitute with whatever mapping you want.  You could even
   extend the generic INT so that your code could reference it the
   same way you are used to.  Not sure I'd recommend extending the
   generic, but it should work.  (I might worry about compilers that
   did their own extension to INT refusing to accept it, though,
   even though the standard says it should work).

2. Some compilers don't "really" treat logicals as a very separate
   type from integers (at least that's the way I describe it).  They
   act like LOGICAL is just a strange way to spell something like
   "unsigned integer" (which I find a bit unintuitive).  A
   particularly common case is using logical*1 to store values from
   0-255.  This is a fairly common extension, but it is certainly not
   universal.  It would make sense for a compiler with this extension
   to define INT() for logical arguments.  (I'm not sure whether such
   compilers actually do define INT() like this because I don't use
   the practice, but it would make sense as part of the extension).
 
   If this is what you are assuming, then there are certainly plenty of
   compilers that don't do it - you just must not have run into them.
   But if this were the case, there would be lots of other things that
   you'd have problems with, not just INT().  There are things like
   (L being a logical)
      L = 123
      if (L .eq. 7) ...
   and a bunch of others.

   If this is your problem, it is more pervasive than just INT() and
   is harder to solve.

3. INT() with a logical arg could act just like TRANSFER - copy the
   bits without paying any attention to their interpretation.  In this
   case, TRANSFER is probably the obvious choice of f90 form.
  
-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%