Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!tut.cis.ohio-state.edu!bloom-beacon!spdcc!husc6!xait!g-rh
From: g-rh@XAIT.Xerox.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Portability of passing/operating on structures...
Message-ID: <35569@XAIT.Xerox.COM>
Date: 25 Oct 88 16:44:23 GMT
Article-I.D.: XAIT.35569
References: <8810111934.AA21941@ucbarpa.Berkeley.EDU> <8308@alice.UUCP> <23933@wlbr.EATON.COM> <1988Oct19.192548.28438@ateng.ateng.com> <35
Reply-To: g-rh@XAIT.Xerox.COM (Richard Harter)
Organization: Xerox Corporation, Cambridge, Massachusetts
Lines: 70

In article <1988Oct24.172209.27031@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes:
>According to g-rh@XAIT.Xerox.COM (Richard Harter):
>>       Yes, I pander to broken compilers.  I have to.

>If I must work with a specific broken compiler, then I do the same: pay for
>play has its own rules.  I was, of course, referring to situations where
>there *is* a choice, such as when writing free software, in which case I
>don't worry about it.

	But how often do you really have a choice of compilers?  If you have
a small machine and you buy your compiler, yes, then you have a choice of
compilers.  If you are in an environment where you have a choice of machines,
each with its own compiler, again you have a choice. 

	More to the point, if your coding practices use constructs and
techniques that break compilers, you are laying problems up for yourself
and others in the future.  

	Different people have different situations.  I have high portability
requirements; others do not.  But I have been at this trade for a long time
and I have noticed that life is a great deal simpler if you, as a matter
of routine, assume that code may have to be ported.  

>>	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.

	More to the point, I do not agree and I am quite sure that many
experience programmers do not agree with your assessment.  There is a cost
associated with learning a language -- the cost for learning to write it
in a clean style is not much different than that of learning to write it
any old way.  Once you've learned what you can and cannot do, coding is 
simply a matter of writing within the language.  Writing in language X
is no harder or easier than writing in language Y, unless a language lacks
a fundamental feature.  Writing clean C is no harder than writing dirty C.
But the price of writing dirty code is high -- debugging dirty code is a
real pain, and it is a gratuitously assumed cost.  

Patient: "Doc, it hurts when I hit myself on the head with a hammer."
Doctor:  "Don't hit yourself on the head with a hammer."
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.