Path: utzoo!mnetor!uunet!husc6!rutgers!mtune!codas!ateng!chip
From: chip@ateng.UUCP (Chip Salzenberg)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <136@ateng.UUCP>
Date: 28 Dec 87 17:48:11 GMT
References: <4668@pyr.gatech.EDU> <495@xyzzy.UUCP> <1987Dec26.162052.26935@sq.uucp>
Reply-To: chip@ateng.UUCP (Chip Salzenberg)
Organization: A T Engineering, Tampa, FL
Lines: 32

In article <1987Dec26.162052.26935@sq.uucp> msb@sq.UUCP (Mark Brader) writes:
>
>> In other words, give me some example of "existing C programs broken" by
>> the draft standard.  I'm not aware of any interesting cases.
>
>[1] One that was just discussed on the net recently... forward references
>    to static functions must, under the Draft, be declared with the keyword
>    "static"; Henry Spencer reports that his compiler will not even accept
>    this syntax.  It'll mean a bunch of changes to sqtroff, for instance.

The practice of using "extern" in a forward reference to a static function
is already non-portable.  For example, the Whitesmith's 68000 compiler used
with older versions of Charles River Data Systems UNOS requires the dpANS
usage for forward references to static functions. (And that's an _old_
compiler!)

>The reason given in the Rationale for [1] is that it will help compilers
>in environments where internal linkage is handled differently from external,
>which would otherwise require an extra pass to handle such code.

I like it.  For example, on the '286 in "large model", static functions
could be made "near", thus improving performance and reducing stack usage.
(Please don't bother posting "the '286 isn't a real computer" flames.)

>Incidentally, there were only 32 comment letters received on the first round.

Could someone please post the info on getting a copy of the draft?  Xanks.

-- 
Chip Salzenberg                 UUCP: "{codas,uunet}!ateng!chip" 
A T Engineering             My employer's opinions are a trade secret.
Chip's Observation:  "Anything that works is better than anything that doesn't."