%ob does not like wide multi-monitors

Strictly speaking, EXTERNAL is required for FUNCTION names passed as a parameter to a subprogram, as otherwise a compiler could flag the name as a variable name.

For example

      EXTERNAL LIAM, MICK
      CALL INIO (JOHN, KEITH, LIAM)
      CALL INIO (JOHN, KEITH, MICK)

would be correctly interpreted as variable, variable, function, but without the EXTERNAL if would be variable, variable, variable.

Until I used Clearwin, I couldn't see the point of this, as if in INIO, LIAM is always used as a function, there is no point in passing its name, and if INIO is sometimes called with LIAM, and sometimes with MICK, one could pass a single value of 1 or 2 (say) and within the routine, call LIAM for 1, and MICK for 2 (or .TRUE. and .FALSE., 0 or 1 etc).

I can't imagine that any compiler/linker throws a sulk if a symbolic name declared EXTERNAL *hasn't *been used in a subprogram call anywhere in the code, and so the habit arose of declaring many or all subprogram names as EXTERNAL, just to show in the source code that they are not simple variables and that they should be searched for a link time. I saw this a lot when I read programs that had (multiple) named BLOCK DATA sections, as these are not otherwise referred to in the source code, and if missing would not be noticed.

It all gets a bit complicated with Fortran 90 et seq.

Eddie

PS I noticed when reading CLEARWIN.INS (v 6.10) that there is this:

      C_EXTERNAL CREATE_INTERPROCESS_SHAERMEM@                          &
     &'__create_interprocess_shared_memory' (STRING,VAL)

Is it a typo, and if so, has it been fixed?

E

Yes I fixed this just a few days ago.

By some reason i do not like declarations of subroutines as external, or just lazy to add somewhere between 1000 and 10000 more lines, but may be i'm still not getting something. I understand that compiler might be confused with the functions (taking them as variables, so i declared that properly despite of it probably was done same 10000 times) but it seems to me that compiler can easily find if this is a subroutine or not because it is always CALLed.

Dan,

There are times, such as a function as an argument, where EXTERNAL must be used. I also try to extend the implicit_none approach to use EXTERNAL to document, at the start of a routine, all routines that are being used. When I do it properly, I find this to be useful to document what can be assumed of this routine for using other functions. It is useful when you come back to maintain or change the code.

This is not really related to the original post, as it has evpolved somewhat.

John

John and Dan,

What does (ab)using EXTERNAL give you that a comment line does not? Indeed, in comments, one can list:

Subroutines CALLed by this subprogram Functions used by this subprogram This subprogram called from ...

(Ab)using EXTERNAL can at best provide the first two, and even then, gives no pointer to which source code file (and line!) to find it in.

You don't need EXTERNAL at all if you go the extra distance and use MODULEs.

Eddie

Modules do not need external -- good. But I still do not see strong reason that subroutines MUST be declared as external for using /DCLVAR for all the rest cases. Compiler can exclude them from that itself.

Also, returning to original restriction on control length - isn't it just possible to increase the limit from current 1280x1280 to say 2560x2560 ?