Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!iuvax!rutgers!cmcl2!yale!wald-david
From: wald-david@CS.YALE.EDU (david wald)
Newsgroups: comp.lang.c
Subject: Addresses of parameters (was Re: Portability of passing/operating ...)
Message-ID: <41337@yale-celray.yale.UUCP>
Date: 25 Oct 88 23:43:29 GMT
References: <8810111934.AA21941@ucbarpa.Berkeley.EDU> <8308@alice.UUCP> <23933@wlbr.EATON.COM> <1988Oct19.192548.28438@ateng.ateng.com> <35 <35569@XAIT.Xerox.COM>
Sender: root@yale.UUCP
Reply-To: wald-david@CS.YALE.EDU (david wald)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 45

In article <35569@XAIT.Xerox.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>In article <1988Oct24.172209.27031@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes:
>>According to g-rh@XAIT.Xerox.COM (Richard Harter):
>>>     And the truth of the matter is that there is no penalty for
>>>writing portable code [...]
>
>>But there *is* a penalty in pandering to broken compilers.  If, for example,
>>a compiler breaks on:
>>
>>      foo(s) short s;
>>      {
>>          short *sp = &s;
>>          int i = *sp;
>>
>>          printf("%d\n", i);
>>      }
>
>>Then you have to invest time and effort into avoiding a language construct
>>-- taking the address of a function parameter -- that should have worked.
>>(I know that some compilers do, in fact, break this contruct.) I'm sure all
>>will agree that spent time and effort are just as much a "penalty" as
>>execution time.
>
>       This is a good example.  It contains two coding techniques that I
>do not use and, indeed, would not think of using.  The first is taking
>the address of a function parameter.  The second is initialization to a
>dynamic quantity.  Why do these things?  The latter is just asking for
>trouble.  The only reason for taking the address of a function parameter
>that I can think of is that you are calling a routine that requires a
>pointer rather than a value.  I don't know whether they are "supposed"
>to work or not and I don't care; they are dubious constructs.

I'm not sure why you consider the first of these a dubious construct.
(The second I am willing to consider a non-portable abbreviation for an
extra line of code.) I can't think of an architecture where this would
be unusually difficult to implement, and on most architectures it would
be as easy as taking the address of any automatic variable.  Is it
dubious only because there are compilers which break on it, or is there
a more basic reason?


============================================================================
David Wald                                              wald-david@yale.UUCP
						       waldave@yalevm.bitnet
============================================================================