Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!leah!itsgw!nysernic!rutgers!sri-spam!mordor!lll-tis!ptsfa!hoptoad!academ!uhnix1!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <279@nuchat.UUCP>
Date: Tue, 4-Aug-87 11:00:16 EDT
Article-I.D.: nuchat.279
Posted: Tue Aug  4 11:00:16 1987
Date-Received: Sat, 15-Aug-87 07:27:50 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <847@haddock.ISC.COM>
Organization: Public Access - Houston, Tx
Lines: 40
Summary: extension flag polarity

In article <847@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
> You are right; I got the terms confused.  In fact A.6.5 says that certain
> common extensions, e.g. nonstandard keywords, will render an implementation
> nonconforming.
> 
> I still think "broken" is too strong a word.  But if I were a compiler vendor
> I'd be certain to have a switch that disabled all extensions to yield a "pure"
> implementation.

Please:

If anyone reading this is ever in a position to affect a decision on
this point, make the silly flags default to the portable, standard
configuration.  I worked on a project that had a major commercial
product running on something like 30 different unix boxes, which at
one time spanned the gamut from v7-based xenix to sys5.2.  There were
three serious time sinks in the porting group, and dealing with the
feature differences among the unix versions wasn't one of them.

Actually getting the code from the base machine to all the targets
(usually over serial lines) consumed a lot of clock time, but was
not too demanding on the people.  Incompatible bugs consumed the
largest amount of time, taken across both the porting staff and
the development group.  If everyone had the same bugs life would
be grand.  Right behind bugs was compiler/linker/make flags.
Figuring out the silly magic required to get company X's compiler
to behave like a unix C compiler took an amazing amount of time.
Particularly if company X was in the intel camp, but it happened
with other processors too.

The stories I could tell.  Anyway, It is a serious presumption
on the part of the compiler vendors to place the burden of groping
through the manual (or disassembling the compiler) on the occasional
user, the application porter.  The guy doing development on the
box can more reasonably be expected to become intimate with its
compiler.

	does any of this make sense?
	Steve Nuchia
	{{soma,academ}!uhnix1,sun!housun}!nuchat!steve