(j3.2006) STAT= and integer kind

[Bill Long]

On Jul 4, 2014, at 1:01 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:

> Oops, I got this confused with the other paper on relaxing default integer 
> constraints... my apologies.
> 
>> in the current TS18508 draft from May,
> 
> That would be the about-to-be-superceded draft...
> 
>> the collectives take for the STAT
>> argument a default-kind integer. On the other hand, 14-173r2 suggest to
>> add a STAT= to the atomic intrinsics which can be any integer kind.
>> 
>> I think it makes sense to be consistent.
> 
> In principle I agree.
> 
> And you are right, 173r2 is applying changes to the TS (and indirectly to F2015 
> via F2008).  Lots of opportunities for confusion there.  Bill Long will be 
> producing a new draft of the TS shortly.
> 
>> Hmm, but F2008 also supports nondefault-kind integers for STAT=, see,
>> e.g., "R628 stat-variable is scalar-int-variable". Admittedly, many
>> (all?) of the STATUS= arguments of the intrinsics use a default-kind
>> integer.
> 
> The latter is being improved.  OTOH, having no restrictions on the kind of 
> integer is not necessarily a good idea, since oftimes the value being assigned 
> is going to be out of range if you only supply an 8-bit integer (especially if 
> the compiler has a unified set of error status codes).  It is better (for 
> portability) if the standard makes some minimal requirements?

I agree with Malcolm?s comments, particularly about the last one regarding minimal requirements on the sizes of integers appropriate for STAT arguments in intrinsics.  I will be putting the text from the meeting papers into the next TS draft, including having default integer STAT arguments.  Changing that would be beyond the limits of editorial repairs.  That is not to say that a later integration into the base standard might include relaxing the limitation on the integer sizes.  

If you are implementing these routines now, you could determine the largest status value your runtime will create and allow any size integers large enough to represent that value. As long as you include default kind integers in the list, you will still be conforming, since conforming programs would use default integers and work correctly.  You would just be providing an extension.  This is one of the extensions that would require a message if the user asked for standard-conformance checking.  If we relaxed the rule during integration, your only change would likely be to disable the conformance message. 

Cheers,
Bill




> 
> Cheers,
> -- 
> ................................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101