Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtp47.UUCP
Path: utzoo!linus!decvax!mcnc!rti-sel!rtp47!throopw
From: throopw@rtp47.UUCP (Wayne Throop)
Newsgroups: net.lang.f77
Subject: Re: when is a function not a function...
Message-ID: <49@rtp47.UUCP>
Date: Sat, 25-May-85 13:33:47 EDT
Article-I.D.: rtp47.49
Posted: Sat May 25 13:33:47 1985
Date-Received: Mon, 27-May-85 03:18:55 EDT
References: <1562@hao.UUCP> <10964@brl-tgr.ARPA>
Organization: Data General, RTP, NC
Lines: 31

> > c This might just be unique to the UNIX(tm) compiler,
> > c  or is it standard that functions can be CALLed
> > c  and subroutines be (almost) treated as functions?
> > 	PROGRAM main
> > 	CALL func1
> > 	dummy = sub1()
> > 	PRINT*,sub1()
> > 	END
>
>   You can do this, since as Doug Gwyn points out, this mis-usage is
> difficult to detect. In fact, calling a function with a call statement is
> a convenient way of invoking a function and ignoring the return value.
> The other example (using a subroutine like a function) will, of course,
> result in an unpredictable return value which may vary from one machine
> to another or even one compiler to another on the same machine.
>
> --Greg

It may be convenient as suggested, but you hadn't better expect either
mistake to be portable.  Granted, the "CALL func" is more likely to
sneak by than the "dummy = sub1()", (and do something reasonable on many
machines) but some points are worth mentioning:

  - Some fortran compilers will catch these errors when the invocation
    occurs in the same file as the definition.
  - Some fortran compilers return function arguments in a "hidden"
    by-reference argument (usually an inserted argument 1).  Hence "CALL
    func" will cause about the same amout of greif as calling a
    subroutine with a missing first argument.
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw