Path: utzoo!attcan!uunet!lll-winken!pacbell!att!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: C vs. FORTRAN Message-ID: <5234@ihlpf.ATT.COM> Date: 8 Jul 88 00:21:11 GMT References: <3136@phoenix.Princeton.EDU> <225800038@uxe.cso.uiuc.edu> <797@garth.UUCP> <5173@ihlpf.ATT.COM> <852@garth.UUCP> <546@philmds.UUCP> <30305@cca.CCA.COM> <872@garth.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 34 In article <872@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: >Actually, the real discussion is why does C have such a crippled argument >list? It is possible to pass a list of argument descriptors. The descriptor >list can be staticcally created and the overhead is just a register load >of a relocated address. This sounds to me that you want call-by-reference instead of call-by-value. Personally, I prefer to have call-by-value and to explicitly say when I am using a variable as a reference (my only exception to this preference is when I am using a const reference). >Why not? Because most of the C users out there are more interested in >speed than security. Is that efficient? Security in FORTRAN (with respect to calling conventions)?? Look at the following piece of pseudoFORTRAN (I haven't used FORTRAN in about four years and the exact syntax escapes me. I'm sorry if I got this slightly wrong, but here are the results when I did this same type of program four years ago): subroutine foo(j) j = 5 end ... call foo(1) This passes through the compiler with no problem. If you look at the run-time error, it's usually a memory violation and not a compiler-generated error. Some security. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) You are in a little twisting maze of / / _ , __o ____ email paths, all different. / (_