Standardising code to Fortran 95...part#n

[Anthony_Richards]

I am looking at standardising some code. I get loads of warnings, so I am starting to go through them.
Please can you advise about the following ones:

It doesn't like the .TRUE. in statements that use it, such as      CHECKED=.TRUE.  or where 'TRUE. is used as an argument in a subroutine call.

It says use of intrinsic procedures LOC() and SIZEOF()  is not allowed.

What can I use instead?

[TimP]

The standard replacements for LOC() and SIZEOF are 'use iso_c_binding' (with c_loc and c_sizeof functions).

Specific examples might be needed for your problems with .true.  What I can think of is that ifort has an extension which would allow .true. to mix with integer data types if you don't ask for standards check.  There are also the options -standard-semantics (implying -fpscomp:logicals) which change the bit pattern of .true. to match the current standard and interoperate with C.

[Steven_L_Intel1]

I'll note that C_LOC and C_SIZEOF are Fortran 2003 features, so if you are really standardizing on Fortran 95 you don't want to use those.

You didn't say what the complaint was about .TRUE. My guess is that you have a type or kind mismatch.  For example, if you had declared an argument to be LOGICAL*1 then that would not match .TRUE..

[Anthony_Richards]

Thanks.

So what value is .TRUE. (or .FALSE. for that matter)?
Should it be INTEGER or LOGICAL?

What about 'TRUE' which I have seen in places?

[TimP]

If you mean what are integer values of logical values (as seen via EQUIVALENCE or TRANSFER), if your program depends on that, it's likely to be a case for standards warning.  f95 didn't mandate any bit patterns.

In the logical(kind) case, .true. or .false.  would need a _kind suffix.

I don't think standards checking applies to namelist files, in case you have that in mind.

[Anthony_Richards]

I presume that the text string .TRUE. in a Fortran file is recognized by the compiler as a LOGICAL quantity, so that if you try and equate it to a quantity defined as INTEGER (e.g. INTGR=.TRUE.), you would get a standards warning if standards > F77 checking were selected, but INTGR would be set to a non-zero integer value, but that if you equated it to a LOGICAL quantity (e.g. LOGCL=.TRUE.), that is acceptable to the standard and you would get no warning and such a quantity LOGCL would be set in the 'TRUE' state.

This is akin to the compiler recognising the text string 'MYSTRING'C in the code as indicating that the programmer would like a CHAR(0) appended to the string during compilation so that the string MYSTRING is stored as a C-string.

[Anthony_Richards]

  warning #5112: Extension to FORTRAN-90: tab formatting

Why does the standard object to tab-formatting, as it is very useful for making code readable?

Also, is it possible to selectively turn off certain warnings, such as those that refer to compiler directives which begin !DEC$ as being non-standard e.g.'warning #7025: This directive is not standard F95'?

ALso also, what about the 'warning #6439: This symbol has too many characters.   [T_IMAGE_RESOURCE_DIRECTORY_ENTRY]' warnings that refer to what look like innoccuous statements such as
ghInstance        = NULL
or
if (id.eq.IDC_CLOSE) then

?

[andrew_4619]

Tab characters are non-standard but you can get VS to convert tabs to a set number of spaces and also get it to insert spaces than you tab so you do not see any difference other than your source files will have a few more bytes,

You can have options like /Qdiag-disable:7025,5142,6477 to suppress warnings for the whole project or for specific source file if you want.

In F90/95, identifiers are limited to 31 characters, Fortran 2003 raises this limit to 63 characters this is warning #6439 i think.

NULL is defined in module IFWIN but also some other modules, check what you are using and what type it is.

[TimP]

I suppose you'll need to set a numeric list of -Qdiag-disable options.

I don't see a change in readability when I switch a source file between tabs and spaces.  It's been a long time since I had to expand tabs explicitly, so I agree the warning isn't normally useful.  

[Steven_L_Intel1]

Whether or not the warning for tab formatting is considered useful, it is valid. A source file with tabs outside of comments and character literals is not standard conforming. I remember that VAX Fortran had an option to exclude "source form" standards warnings, but as noted you can exclude individual diagnostics easily enough.

[Steven_L_Intel1]

On the subject of .TRUE., see Doctor Fortran in "To .EQV. or to .NEQV., that is the question", or "It's only LOGICAL"