Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site laidbak.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!laidbak!jeq
From: jeq@laidbak.UUCP (Jonathan E. Quist)
Newsgroups: net.bizarre
Subject: Re: Bizarre Code
Message-ID: <194@laidbak.UUCP>
Date: Sun, 1-Sep-85 14:05:50 EDT
Article-I.D.: laidbak.194
Posted: Sun Sep  1 14:05:50 1985
Date-Received: Mon, 2-Sep-85 04:34:39 EDT
References: <462@moncol.UUCP> <29712@lanl.ARPA> <554@grkermi.UUCP> <490@moncol.UUCP> <593@grkermi.UUCP>
Reply-To: jeq@laidbak.UUCP (Jonathan E. Quist)
Organization: LAI Chicago
Lines: 95
Summary: 

In article <593@grkermi.UUCP> andrew@grkermi.UUCP (Andrew W. Rogers) writes:
>In article <490@moncol.UUCP> john@moncol.UUCP (John Ruschmeyer) writes:
>>>From: andrew@grkermi.UUCP (Andrew W. Rogers)
>>> [Description of a weird quirk of HP FORTRAN and its loader]
>>
>>Ulp! By any chance did this FORTRAN let you change the value of a constant
>>by passing it to a subroutine, as in:
>>
>>		CALL FOO(2)
>>		.
>>		.
>>		SUBROUTINE FOO(I)
>>		I=I + 2
>>		RETURN
>>		END
>>
>Actually, I've never heard of a FOOTRAN compiler that *wouldn't* let you do
>the above - or even generate a warning!  All parameters in FORTRAN are passed
>by reference and it is just assumed that you won't try anything (deliberately
>or otherwise) like the above.  
>
>Algol (and most of its derivatives) support parameter passing by value as
>well as by reference.  Call-by-reference parameters in Pascal and Ada (yeah,
>I know the latter aren't technically 'by reference') are explicitly flagged
>as such ('var' in Pascal, 'out' in Ada); more importantly, the mode of
>passing each parameter is known to the compiler when processing the call.
>Passing a constant parameter to a routine that might change its value is
>readily detected and results in an error message.  The following programs
>*will not* compile:
>
>	procedure foo(var i: integer);		{ Pascal }
>	begin
>	i := i + 2
>	end;
>	.
>	.
>	foo(2);
>
>
>	procedure FOO(I: in out INTEGER) is	-- Ada
>	begin
>	I := I + 2;
>	end FOO;
>	.
>	.
>	FOO(2);
>
>
>Modern techniques of flow analysis could theoretically catch this sort of
>trap in FORTRAN - *if* FOO were in the same source module as all calls
>to it.  Another solution (depending on machine architecture, memory
>management, and OS design) would be to place all constants in a read-only
>data area.  Attempts to change constant values would either be ignored or 
>generate a run-time error.  (Anyone know of compilers/systems that do either?)
>
>Incidentally, there are several C compilers that allow you to pass the
>address of a constant (apparantly to facilitate interface to - you guessed
>it - FORTRAN subroutines).  The FORTRAN example above could be written as
>
>	foo(&2);
>	.
>	.
>	foo(i)
>	  int *i;
>	{
>	*i += 2;
>	}
>
>(I doubt that even 'lint' would catch this!)
>
>AWR
>
>(Is this the least bizarre posting, or what?)

1Lq% cat foo.c
#include <stdio.h>

main()
{
	foo(&2);
}

foo(i)
short *i;
{
	*i += 2;
}
2Lq% lint foo.c
foo.c:
foo.c(5): unacceptable operand of &
foo.c(5): cannot recover from earlier errors: goodbye!

Irmc.

jeq