Improper argument to UPCASE@ not caught even with /checkmate

Would it be possible to provide built-in interfaces to the Silverfrost utility functions and subroutines such as UPCASE@?

In the following test program, I made the mistake of passing a similarly named integer variable instead of a character variable to UPCASE@. Even with /checkmate, the program crashes with access violation, whether built for 32-bit or 64-bit.

program upc
!test program to show upcase@ bug
implicit none
integer :: ipc = Z'00636261'
character(4) :: cpc = 'pqr '
!
call upcase@(ipc)  !error, should have passed CPC instead of IPC
print *,ipc
print *,cpc
end program

I have made a note to look into this.

... and presumably, LCASE@

E

Yes, thanks for the prompting.

Quoted from John-Silver What's meant by the request:-

...provide built-in interfaces to ....

?

The compiler should know the types of arguments that built-in routines (whether standard 'intrinsics' or Silverfrost extensions), and should be able to check that actual arguments in calls to such routines are of the correct types (or compatible, at least).

Argument type checking has now been added to FTN95 for UPCASE@, LCASE@ and about 80 other native intrinsics. This will be included in the next release of FTN95.

Paul,

That's excellent. There are loads of subprograms in FTN that have their origins in FTN77, and it's great that they are being kept up to date.

Is it possible to have a list of what the SF routines are, above and beyond what are in the standard, please? I keep forgetting to look in the FTN77 manuals.

Eddie

Here is the list without the trailing @ or $. There are some native intrinsics that are currently not tested. In particular only routines ending in @ or $ are tested.

ALLOCSTR,APPEND_STRING,ATTACH,CENTRE,CISSUE,CLOCK,CLOSEF,CLOSEFD, CNUM,COMPRESS,CONVDATE,COU,COUA,CURRENT_DIR,DCLOCK,DOSERR,DOSPARAM, DOS_ERROR_MESSAGE,EMPTY,ERASE,ERROR,EXIT,FEXISTS,FILEINFO,FILE_EXISTS, FILE_SIZE,FILE_SIZE8,FILE_TRUNCATE,FLUSH_FORTRAN_HANDLE,FORTRAN_ERROR_MESSAGE, FPOS,FPOSLONG,FPOS_EOF,FPOS_EOFLONG,GETENV,GETENVIRON,GETSTR,GET_CURRENT_FORTRAN_UNIT, GET_GSTORAGE,GET_GSTORAGE64,GET_KEY,GET_KEY_OR_YIELD,GET_PATH,GET_PROGRAM_NAME, GET_STORAGE,GET_STORAGE64,GLOBALMEMORYSTATUS,LCASE,MKDIR,NONBLK,OPENF, OPENR,OPENRW,OPENW,PRERR,PROCESSMEMORYINFO,READF,READFA,READFLONG,RENAME, RETURN_GSTORAGE,RETURN_STORAGE,RFPOS,RFPOSLONG,RUNERR,SET_FILE_ATTRIBUTE, SET_SEED,SLEEP,SLEEP1,SOUND,START_PPROCESS,START_PROCESS,TEMP_FILE,TEMP_PATH, TRIM,TRIMR,UPCASE,WRITEF,WRITEFA,WRITEFLONG

Paul,

Many thanks for the quick response.

I once had a school report that 'Edward is easily amused.' It was nearly 60 years ago, and I still am. It's that mischievous easily amused sense that makes me chortle ar 'READFA'. Perhaps it just needs to be complemented with 'DOFA' and 'PRINTFA' for completeness.

Eddie

PS. For those who don't understand the meaning of 'FA', please send me a PM and I will explain.

This kind of argument type checking has now been extended to the routines in clearwin.ins. REF and VAL keywords in this header file have been extended by the simple expediency of adding one character that represents the type (for example, REFD for double precision and REF3 for INTEGER(3)).

This will be included in the next full release and, after an initial trial period, the aim is to include this information in the corresponding module CLRWIN for a subsequent release. So initially you will get better diagnostics by using the header file rather than the module.

Paul, this is a welcome addition to the error catching capabilities of FTN95 and will be appreciated by the many users of this compiler.

I'd like to add my voice in support of updating those excellent but rather old facilities that have carried over from the early days of FTN77 and which continue to be useful. Keeping them current is a valuable enhancement.

When the DBOS graphics system was converted to Windows, several of the functions fell by the wayside. One set of them included CREATE_POLYGON@, COMBINE_POLYGONS@, DELETE_POLYGON@ and MOVE_POLYGON@ - a set of useful drawing tools for which CW+ has no replacement, despite FTN95 saying that there is.

Also, especially in connection with the drawing of equations and mathematical functions, the loss of DRAW_HERSHEY@ (and HERSHEY_PRESENT@) is a bit of a pity too.

Eddie

CREATE_POLYGON@ etc. should work for 32 bits. These are hard-wired (no header required) into salflibc.dll. They were also ported as CREATE_POLYGON_L@ etc. which are available via clearwin.ins. I have tested the latter set and they work for me.

CREATE_POLYGON_L@ etc. have now been ported to 64 bits. Also two new routines have been added to this set (both 32 and 64 bits) namely DRAW_POLYGON_L@ and COPY_POLYGON_L@. You will also be able to use smoothing with this update when it is released.

I have not looked at the HERSHEY routines but the original DBOS routines are present for 32 bits in salflibc.dll.

Quoted from LitusSaxonicum It's that mischievous easily amused sense that makes me chortle ar 'READFA'. PS. For those who don't understand the meaning of 'FA', please send me a PM and I will explain.

in READFA FA as well as in READF F means exactly what FA and F means: eFfin FAst. I'm sure all know what effing means but i'm also sure no one knows HOW is it fast. Hell fast.

Dan,

The F means what you assumed, A means 'All', a combination which in colloquial British English means 'nothing', so READFA means 'Read nothing'.

I only know this because for most of my life I appear to have worked amongst sufferers from Tourrette's Syndrome, which it appears is infectious.

Eddie

Paul,

I'm an avid reader of documentation, but had completely missed the things in your reply - it never occurred to me to read the .INS file in this context, especially as FTN95.CHM suggests something rather different. It's obviously something to mull over and try out. Many thanks.

Eddie