Addresses of parameters (was Re: Portability of passing/operating ...)

david wald wald-david at CS.YALE.EDU
Wed Oct 26 09:43:29 AEST 1988


In article <35569 at XAIT.Xerox.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
>In article <1988Oct24.172209.27031 at ateng.ateng.com> chip at ateng.ateng.com (Chip Salzenberg) writes:
>>According to g-rh at 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 at yale.UUCP
						       waldave at yalevm.bitnet
============================================================================



More information about the Comp.lang.c mailing list