Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #14444 > unrolled thread

When did K&R function declarations become obsolete?

Back to article view | Back to comp.lang.c

Contents

  When did K&R function declarations become obsolete? Alan Mackenzie <acm@muc.de> - 2011-12-10 18:23 +0000
    Re: When did K&R function declarations become obsolete? Kaz Kylheku <kaz@kylheku.com> - 2011-12-10 18:41 +0000
    Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-10 10:40 -0800
      Re: When did K&R function declarations become obsolete? Ian Collins <ian-news@hotmail.com> - 2011-12-11 07:49 +1300
      Re: When did K&R function declarations become obsolete? Ben Pfaff <blp@cs.stanford.edu> - 2011-12-10 10:49 -0800
    Re: When did K&R function declarations become obsolete? jt@toerring.de (Jens Thoms Toerring) - 2011-12-10 21:16 +0000
      Re: When did K&R function declarations become obsolete? Alan Mackenzie <acm@muc.de> - 2011-12-12 11:29 +0000
        Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-12 03:49 -0800
        Re: When did K&R function declarations become obsolete? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-12 15:04 +0000
          Re: When did K&R function declarations become obsolete? Alan Mackenzie <acm@muc.de> - 2011-12-13 10:42 +0000
            Re: When did K&R function declarations become obsolete? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-13 13:58 +0000
              Re: When did K&R function declarations become obsolete? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-12-13 10:17 -0500
                Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-13 12:04 -0600
                  Re: When did K&R function declarations become obsolete? Kaz Kylheku <kaz@kylheku.com> - 2011-12-13 18:17 +0000
                    Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-13 15:17 -0600
                      Re: When did K&R function declarations become obsolete? Kaz Kylheku <kaz@kylheku.com> - 2011-12-13 21:46 +0000
                        Re: When did K&R function declarations become obsolete? Seebs <usenet-nospam@seebs.net> - 2011-12-13 22:04 +0000
                          Re: When did K&R function declarations become obsolete? jgk@panix.com (Joe keane) - 2011-12-13 23:07 +0000
                            Re: When did K&R function declarations become obsolete? Seebs <usenet-nospam@seebs.net> - 2011-12-13 23:23 +0000
                              Re: When did K&R function declarations become obsolete? Kaz Kylheku <kaz@kylheku.com> - 2011-12-14 00:26 +0000
                            Re: When did K&R function declarations become obsolete? blp@cs.stanford.edu (Ben Pfaff) - 2011-12-13 15:22 -0800
                            Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-13 15:27 -0800
                        Re: When did K&R function declarations become obsolete? Alan Mackenzie <acm@muc.de> - 2011-12-14 09:33 +0000
                Re: When did K&R function declarations become obsolete? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-13 19:49 +0000
                  Re: When did K&R function declarations become obsolete? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-12-13 14:54 -0500
      Re: When did K&R function declarations become obsolete? luser- -droog <mijoryx@yahoo.com> - 2011-12-20 02:28 -0800
    Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-10 13:48 -0800
      Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-10 21:48 -0800
    Re: When did K&R function declarations become obsolete? Ralph Spitzner <rasp@spitzner.org> - 2011-12-11 04:16 +0100
      Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-10 21:54 -0800
    Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-10 22:27 -0600
      Re: When did K&R function declarations become obsolete? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-11 12:56 +0000
        Re: When did K&R function declarations become obsolete? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-11 09:11 -0500
          Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-11 21:40 -0600
            Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-12 00:05 -0800
              Re: When did K&R function declarations become obsolete? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-12 15:00 +0000
                Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-12 07:18 -0800
                  Re: When did K&R function declarations become obsolete? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-13 00:55 -0800
                    Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-13 07:50 -0800
                Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-12 11:15 -0600
              Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-12 11:17 -0600
                Re: When did K&R function declarations become obsolete? jgk@panix.com (Joe keane) - 2011-12-12 21:57 +0000
                  Re: When did K&R function declarations become obsolete? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-12 18:15 -0500
        Re: When did K&R function declarations become obsolete? ralph <nt_consulting64@yahoo.net> - 2011-12-11 15:10 -0600
    Re: When did K&R function declarations become obsolete? James Kuyper <jameskuyper@verizon.net> - 2011-12-11 09:17 -0500
      Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-11 06:53 -0800
        Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-12 00:08 -0800
      Re: When did K&R function declarations become obsolete? Alan Mackenzie <acm@muc.de> - 2011-12-12 11:59 +0000
        Re: When did K&R function declarations become obsolete? James Kuyper <jameskuyper@verizon.net> - 2011-12-12 07:47 -0500
          Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-12 11:59 -0800
            Re: When did K&R function declarations become obsolete? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-12 18:17 -0500
              Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-12 15:43 -0800
        Re: When did K&R function declarations become obsolete? André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-12 13:49 +0100
          Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-12 05:25 -0800
            Re: When did K&R function declarations become obsolete? André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-12 14:35 +0100
        Re: When did K&R function declarations become obsolete? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-12 15:21 +0000
    Re: When did K&R function declarations become obsolete? Jonathan Leffler <jleffler@earthlink.net> - 2011-12-13 22:19 -0800
      Re: When did K&R function declarations become obsolete? Keith Thompson <kst-u@mib.org> - 2011-12-14 02:54 -0800
        Re: When did K&R function declarations become obsolete? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-14 13:17 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14581

jgk@panix.com (Joe keane) writes:

> In article <slrnjefiv9.45t.usenet-nospam@guild.seebs.net>,
> Seebs  <usenet-nospam@seebs.net> wrote:
>>	extern int foo();
>>	extern int foo(char *, double);
>
> My onion is that no one gives a rat's behind about the syntax for how
> functions are -defined- [i like old one better] but putting types where
> they are -declared- is worth about five other features combined.

I'm not sure of what relationship you are suggesting between an
onion and a rat's behind, but I think that it's rather nice to
have the declaration and the definition take the same form, that
is, I appreciate not having to write the definition differently
from the prototype.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#14582

jgk@panix.com (Joe keane) writes:
> In article <slrnjefiv9.45t.usenet-nospam@guild.seebs.net>,
> Seebs  <usenet-nospam@seebs.net> wrote:
>>	extern int foo();
>>	extern int foo(char *, double);
>
> My onion is that no one gives a rat's behind about the syntax for how
> functions are -defined- [i like old one better] but putting types where
> they are -declared- is worth about five other features combined.
>
> Maybe you could make a utility that checks across source files?

Certainly some people do care about the syntax of function definitions.

Personally, I prefer the "new-style" (actually several decades old)
definitions, mostly because they're consistent with "new-style"
declarations.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14597

Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2011-12-13, ralph <nt_consulting64@yahoo.net> wrote:
>> On Tue, 13 Dec 2011 18:17:00 +0000 (UTC), Kaz Kylheku
>><kaz@kylheku.com> wrote:

>>>Given that such things work fine for languages that don't have header
>>>files and declarations, I'm somewhat skeptical.

>> Skeptical of what?

>> That it isn't easier to write a browser, editor macros, or other
>> development utilites for C code that has prototypes compared to free
>> form code that doesn't? That's kind of silly, IMHO.
 
> Yes.

> It's no harder to extract the same information from

>  int foo(a, b)
>  char *a;
>  double b;
>  {

> than from

>  int foo(char *, double b)
>  {

> which is what I think your point boils down to.

As I explained yesterday, it is harder for an editor (in particular,
Emacs).  There, parsing is done backwards, finding the syntactic context
of a particular line.  Old style definitions are a royal pain in the
arsenic.  The type definitions in them are the one thing in C which isn't
context free.  (C++ is much worse.)

-- 
Alan Mackenzie (Nuremberg, Germany).

[toc] | [prev] | [next] | [standalone]

#14567

"Scott Fluhrer" <sfluhrer@ix.netcom.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:0.bfa81e69542c0fc48709.20111213135813GMT.87borcmv4a.fsf@bsb.me.uk...
>> Alan Mackenzie <acm@muc.de> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> Alan Mackenzie <acm@muc.de> writes:
>>>> <snip>
>>>>>                                           It's just that there is a
>>>>> new option to disable K&R header parsing - this parsing can be
>>>>> inordinately slow, for example when there are long sequences of 
>>>>> variable
>>>>> declarations (which might be K&R parameter specifications).  It's a 
>>>>> shame
>>>>> to impose this performance penalty on everybody, just because of some
>>>>> obsolete construct which "nobody" uses any more.
>>>
>>>> Can you expand on this?  I can't see why it would be particularly slow.
>>>> Your description hints at some hard to resolve ambiguity with old-style
>>>> function declarations.
>>>
>>> Certainly.  There's a lisp function c-in-knr-argdecl which determines
>>> whether the current position is inside a K&R section.  It basically
>>> searches back over (what look like) variable declarations till it comes
>>> to a ')' which isn't followed by a ';'.  It then performs some extra
>>> checks.  If there is no such ')' but large numbers of variable
>>> declarations, c-in-knr-argdecl could be searching an awful long way.  To
>>> counteract this danger, there is an arbitrary limit (20) on the number of
>>> parameters.  Even with this limit, things can get a bit sluggish.
>>
>> Sorry, I'd forgotten the context -- I though you were saying that it was
>> slow to parse in the normal sense.
>
> I suspect that this is the problem; the compiler sees the tokens:
>
> foo(a, b, c, d, e, f)
>
> Is this a call to the function foo, or is this the start of a K&R definition 
> of the function 'foo'?

You use of "the problem" is confusing.  Alan Mackenzie explained what the
problem was that he and I were talking about, and it's not to do with
compiling but parsing inside an editor.

I think you are suggesting that there is "another problem".

> Now, in standard C, there really isn't such an ambiguity; a call to a 
> function can occur only within another function, while function definitions 
> can occur only at global level.  However, I suspect that the OP is talking 
> about GCC (or a similar compiler), which allows functions to be defined in 
> other functions -- in that case, this ambiguity might happen a lot.
>
> Personal opinions: I'd suspect that just forbidding implicit types of 
> functions-within-other-functions (so it'd have to be 'int foo(a,b,c,d,e,f)' 
> would be sufficient to break up the ambiguity in the most common cases.  On 
> the other hand, as far as I am concerned, K&R function declarations became 
> obsolete the first time a function prototype caught an error of mine that 
> would have taken me hours to track down otherwise.

Standard C (C99 that is) both forbids nested function *and* has removed
implicit int in declarations, so there is (doubly!) no ambiguity.

My own person opinion: I think it's a shame that ',' was chosen to
separate function parameter declarations.  I would have used the compact
form available for declarations generally:

  int foo(int a, b, c; double *sum);

When they don't need to be named one would prefer

  int foo(int; int; int; double *);

but, just to keep things uniform, I think the syntax might

  int foo(int ,,; double *);

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14570

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.fbfbfabd314735c90fbc.20111213194943GMT.87wra0l0a0.fsf@bsb.me.uk...
> "Scott Fluhrer" <sfluhrer@ix.netcom.com> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:0.bfa81e69542c0fc48709.20111213135813GMT.87borcmv4a.fsf@bsb.me.uk...
>>> Alan Mackenzie <acm@muc.de> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>> <snip>
>>>>>>                                           It's just that there is a
>>>>>> new option to disable K&R header parsing - this parsing can be
>>>>>> inordinately slow, for example when there are long sequences of
>>>>>> variable
>>>>>> declarations (which might be K&R parameter specifications).  It's a
>>>>>> shame
>>>>>> to impose this performance penalty on everybody, just because of some
>>>>>> obsolete construct which "nobody" uses any more.
>>>>
>>>>> Can you expand on this?  I can't see why it would be particularly 
>>>>> slow.
>>>>> Your description hints at some hard to resolve ambiguity with 
>>>>> old-style
>>>>> function declarations.
>>>>
>>>> Certainly.  There's a lisp function c-in-knr-argdecl which determines
>>>> whether the current position is inside a K&R section.  It basically
>>>> searches back over (what look like) variable declarations till it comes
>>>> to a ')' which isn't followed by a ';'.  It then performs some extra
>>>> checks.  If there is no such ')' but large numbers of variable
>>>> declarations, c-in-knr-argdecl could be searching an awful long way. 
>>>> To
>>>> counteract this danger, there is an arbitrary limit (20) on the number 
>>>> of
>>>> parameters.  Even with this limit, things can get a bit sluggish.
>>>
>>> Sorry, I'd forgotten the context -- I though you were saying that it was
>>> slow to parse in the normal sense.
>>
>> I suspect that this is the problem; the compiler sees the tokens:
>>
>> foo(a, b, c, d, e, f)
>>
>> Is this a call to the function foo, or is this the start of a K&R 
>> definition
>> of the function 'foo'?
>
> You use of "the problem" is confusing.  Alan Mackenzie explained what the
> problem was that he and I were talking about, and it's not to do with
> compiling but parsing inside an editor.

Oops, I missed that; I assumed he was talking about parsing within a 
compiler.  Sorry...

-- 
poncho

[toc] | [prev] | [next] | [standalone]

#14785

On Dec 10, 3:16 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> Alan Mackenzie <a...@muc.de> wrote:
> > I think we can say that K&R function declarations are truly obsolete.  In
> > ~20 years of hacking C, I've only seen very old code which uses them.
> > Presumably these declarations are still widely used in compiler validation
> > suites but nowhere else.
> > Approximately when did they become obsolete, i.e. not used at all for new
> > code?
>
> When I started using C in 1989 they were still quite common to be
> seen in code I was looking at but that dropped significantly during
> the following decade and I hardly ever have seen code using them
> written in this millenium. So my very personal guess is that most
> people use the "new" form since at least about 1995.

Mid-90s seems about right. I've got Johnson & Reichard, X Window
Applications Programming, 2ed, from 1992 that still has K&R function
declarations. But, of course, they'd been maintaining that code since
about 1985.

[toc] | [prev] | [next] | [standalone]

#14456

Alan Mackenzie <acm@muc.de> writes:
> I think we can say that K&R function declarations are truly obsolete.  In
> ~20 years of hacking C, I've only seen very old code which uses them.
>
> Presumably these declarations are still widely used in compiler validation
> suites but nowhere else.
>
> Approximately when did they become obsolete, i.e. not used at all for new
> code?
>
> [Context: I'm writing documentation for Emacs's C Mode.]

I'm not aware that they've ever become completely obsolete in that
sense.  One poster in comp.std.c, Jun Woong, is apparently still using
them (unnecessarily IMHO, but I can see his point); see Message-ID
<923cd9a6-c717-478e-89f9-d04d03b7205c@p2g2000vbj.googlegroups.com>,
<http://groups.google.com/group/comp.std.c/msg/819a7f3553366ef8>.

They've been *obsolescent* since C89 (see 6.9.4 and 6.9.5 in the
C90 standard, presumably 3.9.4 and 3.9.5 in the C99 standard),
and remain so in the latest C201X draft.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14475

Keith Thompson <kst-u@mib.org> writes:
[...]
> They've been *obsolescent* since C89 (see 6.9.4 and 6.9.5 in the
> C90 standard, presumably 3.9.4 and 3.9.5 in the C99 standard),
> and remain so in the latest C201X draft.

Sorry, I meant 3.9.4 and 3.9.5 in the ANSI C89 standard.  (ISO C90
described the same language, but renumbered the sections.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14470

Alan Mackenzie wrote:
> I think we can say that K&R function declarations are truly obsolete.  In
> ~20 years of hacking C, I've only seen very old code which uses them.

Sorry, but having read the thread so far I still don't get it.
Are you guys talking about declarations, or implementations ?

After all to avoid an implicit declaration as 'int (void)'
(or (int), for that matter) one would have to declare in some.h like:

char *myfunc(char *);

then implement it as either

char *
myfunc(char *thestring)
{
...
}

or old

char *myfunc(thestring)
char *thestring;
{
...
}

What am I missing here, a proper C course ? :-P

	-rasp

[toc] | [prev] | [next] | [standalone]

#14476

Ralph Spitzner <rasp@spitzner.org> writes:
> Alan Mackenzie wrote:
>> I think we can say that K&R function declarations are truly obsolete.  In
>> ~20 years of hacking C, I've only seen very old code which uses them.
>
> Sorry, but having read the thread so far I still don't get it.
> Are you guys talking about declarations, or implementations ?

The question was about declarations.  (By "implementations", I presume
you mean function definitions.)

> After all to avoid an implicit declaration as 'int (void)'
> (or (int), for that matter) one would have to declare in some.h like:
>
> char *myfunc(char *);

Or as

char *myfunc(char *thestring);

Or, if for some reason you want to use an old-style declaration, you
could declare it as:

    char *myfunc();

and as long as you call it with a char* argument you're ok.

> then implement it as either
>
> char *
> myfunc(char *thestring)
> {
> ...
> }

That's the preferred way, yes.

(I suppose you can have an new-style declaration with an old-style
definition, or vice versa.  I never really thought about it, since I
avoid both old-style declarationd and old-style definitions.)

C99 no longer has implicit int declarations.  Calling a function with no
visible declaration is a constraint violation.  (That declaration may or
may not be a prototype, though).

> or old
>
> char *myfunc(thestring)
> char *thestring;
> {
> ...
> }

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14471

On Sat, 10 Dec 2011 18:23:19 +0000 (UTC), Alan Mackenzie <acm@muc.de>
wrote:

>I think we can say that K&R function declarations are truly obsolete.  In
>~20 years of hacking C, I've only seen very old code which uses them.
>
>Presumably these declarations are still widely used in compiler validation
>suites but nowhere else.
>
>Approximately when did they become obsolete, i.e. not used at all for new
>code?
>
>[Context: I'm writing documentation for Emacs's C Mode.]

As Mr. Thompson pointed out the closest to an "official" date would be
C89, however K&R fell out of common use long before that. Most C
compilers I used by the early 80s offered vendor specific
implementations that supported the "ANSI style", though there wasn't
any official 'ANSI' yet.

The only C compiler I remember by name and version is Microsoft C 3.0
(XENIX) and it was what we would call fully "ANSI compatible" in 1985.
Other platform compilers I used earlier all had the ANSI-style option
available before then. And we all quickly jumped at using it whenever
it was available.

[The reason I'm so vague is because back then just about every box
came with its own "C compiler" or managment sprang for some 3rd-party
"development package" - the fine-print contained a copyright of some
sort but you seldom paid much attention to it, unless there was a
difference in some obscure library. And then you were likely to code a
conditional compile for the "VAX-C", or for accounting's "XENIX-BOX",
etc.]

I've been trying to remember when I last was forced to use pure K&R
and I think it was a DEC VAX/VMS project in 1983???

-ralph

[toc] | [prev] | [next] | [standalone]

#14479

ralph <nt_consulting64@yahoo.net> writes:

> On Sat, 10 Dec 2011 18:23:19 +0000 (UTC), Alan Mackenzie <acm@muc.de>
> wrote:
>
>>I think we can say that K&R function declarations are truly obsolete.  In
>>~20 years of hacking C, I've only seen very old code which uses them.
>>
>>Presumably these declarations are still widely used in compiler validation
>>suites but nowhere else.
>>
>>Approximately when did they become obsolete, i.e. not used at all for new
>>code?
>>
>>[Context: I'm writing documentation for Emacs's C Mode.]
>
> As Mr. Thompson pointed out the closest to an "official" date would be
> C89, however K&R fell out of common use long before that. Most C
> compilers I used by the early 80s offered vendor specific
> implementations that supported the "ANSI style", though there wasn't
> any official 'ANSI' yet.

In contrast, I remember using old-style declarations into to the early
90s for maximum portability.  These were the days when a lot of software
was expensive, and not everyone upgraded their compilers as soon as they
might.

It's possible that I was being over-cautious -- maybe everyone in world
had a prototype-aware C compiler by 1990 -- but that seems unlikely.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14481

On 12/11/2011 7:56 AM, Ben Bacarisse wrote:
> ralph<nt_consulting64@yahoo.net>  writes:
>> [...]
>> As Mr. Thompson pointed out the closest to an "official" date would be
>> C89, however K&R fell out of common use long before that. Most C
>> compilers I used by the early 80s offered vendor specific
>> implementations that supported the "ANSI style", though there wasn't
>> any official 'ANSI' yet.

     You encountered "ANSI style" compilers in the "early 80s?" Six,
seven, eight years before the Standard became final?  That's some
pretty impressive tea-leaf reading ...

     The Standard was a moving target during most of its development.
The first draft I read included the `noalias' keyword -- and that was
in 1988, only about twenty months before ANSI's formal adoption!  Did
the compilers you recall support `noalias'?

> In contrast, I remember using old-style declarations into to the early
> 90s for maximum portability.  These were the days when a lot of software
> was expensive, and not everyone upgraded their compilers as soon as they
> might.

     Ben's experience matches mine, but it wasn't a reluctance to
upgrade compilers that motivated us to keep using old style: It was
the large body of existing old-style code, and the certainty that
we would introduce gratuitous bugs in the course of a translation
effort.  For some strange reason, our engineering management was not
highly motivated to expend programming and Q/A effort on a project
that would have no customer-visible effect except new bugs ...

     We used ANSI-capable compilers to process our K&R-style code.
On some platforms we had to implement work-arounds to get pre-ANSI
effects from an ANSI compiler, just so our pre-ANSI code would continue
to work as it had.

> It's possible that I was being over-cautious -- maybe everyone in world
> had a prototype-aware C compiler by 1990 -- but that seems unlikely.

     Not in 1990, certainly.  By 1993 or so I think "everyone who was
anyone" offered an ANSI/ISO implementation.  Still, though, the amount
of code written post-ANSI was tiny compared to what had been written
in the preceding twenty years.

     Also, that existing investment in pre-ANSI code couldn't be
ANSIfied easily and mechanically.  It wasn't just a matter of adding
prototypes (of which more below), but of sorting out other practices
that had varied across C dialects and that ANSI had standardized.
Replacing `<strings.h>' was fairly simple, replacing `<varargs.h>'
was harder, dealing with whether `unsigned short' promoted to `int'
or to `unsigned int' was harder still, and the litany of glitches
large and small didn't stop there.  ANSIfying several million lines
of pre-ANSI code while it was under active development was not a
project for a part-time summer intern!

     As for writing prototype declarations to match K&R-style function
definitions, it's not always possible.  The K&R definition expects an
argument that has been subjected to what ANSI calls the "default
argument promotions," and the difficulty is in naming the promoted
type.  The implementation gets to make an idiosyncratic decision about
the nature of some types: `enum WhatAmI' is compatible with some kind
of integer, but each implementation gets to make its own decision --
and that decision can influence how a value of that type promotes.
A K&R function with an `enum WhatAmI' parameter may need to be
declared with different prototypes on different systems.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#14487

On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 12/11/2011 7:56 AM, Ben Bacarisse wrote:
>> ralph<nt_consulting64@yahoo.net>  writes:
>>> [...]
>>> As Mr. Thompson pointed out the closest to an "official" date would be
>>> C89, however K&R fell out of common use long before that. Most C
>>> compilers I used by the early 80s offered vendor specific
>>> implementations that supported the "ANSI style", though there wasn't
>>> any official 'ANSI' yet.
>
>     You encountered "ANSI style" compilers in the "early 80s?" Six,
>seven, eight years before the Standard became final?  That's some
>pretty impressive tea-leaf reading ...
>

I can appreciate your disbelief especially if one might be used to
today's environment where the usual process is to develop a "standard"
and then sit back and watch various vendors move to support the new
standard.

Such was not the case with C. In computer-years an official 'standard'
was a long, long time coming. I started using C in 1977 (a year before
they published the book. <g>) There wasn't a 'Standard' till 1986.
That was almost 10 years since I started, and ~15 years after it was
invented.

Do you seriously believe the vendors sat still all that time waiting?

I tried to be very careful and use the expressions "ANSI style",
"ANSI-Compatibility" in quotes, because as a side issue I'm not sure
when we started applying the term "ANSI". If memory serves we used to
call the extensions "Standard C" as opposed to "K&R C".

>     The Standard was a moving target during most of its development.
>The first draft I read included the `noalias' keyword -- and that was
>in 1988, only about twenty months before ANSI's formal adoption!  Did
>the compilers you recall support `noalias'?
>

Wasn't so much a "moving target" as a classic battle between those who
wanted the standard to agree with the existing implementations at the
time, and those who wanted to define an "even better" language.

Thankfully, the "implementers" pretty much won out. C86 added little
that wasn't already out there.

The "-noalias" option was one of the latter ideas. Don't know if I
ever used a compiler that offered that keyword. I only know I never
used it. I vaguely remember it as an optimizing option, but believe it
applied to whole code blocks not to any one variable.

[Sidnote: I probably wouldn't use it now that I took the time to look
it up. I remember too well the lesson learned with the 'register'
keyword. I jumped on that bandwagon after reading the specs when it
first showed up. Spending time 'n effort to pre-think ways to make my
code more efficient - only to discover that most compiles ignored it
or placed candidates in the register anyway. <g> I seldom bother
anymore, unless testing demonstrated it as needed in a critical
section. Again, no point in anyone flaming me, just my opinion.]

>> In contrast, I remember using old-style declarations into to the early
>> 90s for maximum portability.  These were the days when a lot of software
>> was expensive, and not everyone upgraded their compilers as soon as they
>> might.
>
>     Ben's experience matches mine, but it wasn't a reluctance to
>upgrade compilers that motivated us to keep using old style: It was
>the large body of existing old-style code, and the certainty that
>we would introduce gratuitous bugs in the course of a translation
>effort.  For some strange reason, our engineering management was not
>highly motivated to expend programming and Q/A effort on a project
>that would have no customer-visible effect except new bugs ...
>
>     We used ANSI-capable compilers to process our K&R-style code.
>On some platforms we had to implement work-arounds to get pre-ANSI
>effects from an ANSI compiler, just so our pre-ANSI code would continue
>to work as it had.
>

That is interesting and once again points to the vast differences in
experience and what I might call one's "world view".

I was generally a contract programmer. I was never placed in a
situation where I had to deal with humongous amounts of legacy code.
It was either to add some functionality - in which case I just adopted
whatever 'style' was currently in use, or more common totally new
projects - in which case I used whatever I liked, and I liked
vendor-extensions.

You might add to that (at the definite risk of starting another
flame-war <g>) I have never been a big believer in "portable code".
That is, never a slave to the idea that what I wrote needed to be
portable to a vast array of various operating systems. UNLESS it was
business requirement that it compile and run on multiple OS's. I also
'liked' platform-specific extensions. Especially as in most cases
there was a good reason they were available.

I wrote for the target at hand with the best tools available.

Like I said before - the few situations where differences were
substantial, ie, demanded to be addressed - I often fell back on
conditional compiles and even re-writing whole blocks of code. Better
an application performs to its best on all required platforms.

I always felt adhering to "K&R C" as some kind of "lowest common
denominator" was a silly limitation dreamed up by code lawyers sitting
in a committee with nothing else to do. <g>

But I don't argue with those who do. They have a point. If they are
signing the check then I'll even agree with them... till the next job.

[As a side note. (As though I haven't stirred up enough trouble. <g>)
I never been a big fan of an, or make that THE "enterprise" compiler.
I feel using one through out a single or suite of projects makes
obvious sense. But to delay moving on to something better for a round
of new projects makes more sense. There is no reason to keep using
SmithC v3 just because you wrote your applications with it 5 years
ago.

Of course if SmithC v3 still works just fine, then keep it. I'm NOT
advocating moving on just because something is new, only if new
translates to "better" for your business requirements.

Keep SmithC around for the legacy stuff.]

But again, that likely depends on one's experience and comfort level.
As a contractor I became very used to using multiple compilers on
different boxes at the same time. Never expected the same code to work
exactly the same everywhere, thus never surprised when it didn't, nor
thought twice when I had to go some extra effort to make it work.

>> It's possible that I was being over-cautious -- maybe everyone in world
>> had a prototype-aware C compiler by 1990 -- but that seems unlikely.
>
>     Not in 1990, certainly.  By 1993 or so I think "everyone who was
>anyone" offered an ANSI/ISO implementation.  Still, though, the amount
>of code written post-ANSI was tiny compared to what had been written
>in the preceding twenty years.
>

Like I said, I was no longer using or considering "K&R C" as any kind
of "standard" at least by 1985. Can't remember a single shop that made
it requirement since then either. But that is just me. I obviously
never worked in your shop. (Or likely to have stayed long if I did.
<bg>)

>     Also, that existing investment in pre-ANSI code couldn't be
>ANSIfied easily and mechanically.  It wasn't just a matter of adding
>prototypes (of which more below), but of sorting out other practices
>that had varied across C dialects and that ANSI had standardized.
>Replacing `<strings.h>' was fairly simple, replacing `<varargs.h>'
>was harder, dealing with whether `unsigned short' promoted to `int'
>or to `unsigned int' was harder still, and the litany of glitches
>large and small didn't stop there.  ANSIfying several million lines
>of pre-ANSI code while it was under active development was not a
>project for a part-time summer intern!
>

Doesn't sound like it. Makes me very glad it was never an issue for
me.

>     As for writing prototype declarations to match K&R-style function
>definitions, it's not always possible.  The K&R definition expects an
>argument that has been subjected to what ANSI calls the "default
>argument promotions," and the difficulty is in naming the promoted
>type.  The implementation gets to make an idiosyncratic decision about
>the nature of some types: `enum WhatAmI' is compatible with some kind
>of integer, but each implementation gets to make its own decision --
>and that decision can influence how a value of that type promotes.
>A K&R function with an `enum WhatAmI' parameter may need to be
>declared with different prototypes on different systems.

Ha. Never ran into that because I've never considered K&R C anything
to write for or towards. The book was a good guide, but ultimately it
was only a summary of "here is how it should work", after that one had
to address what it was their current compiler actually did. 

-ralph

[toc] | [prev] | [next] | [standalone]

#14488

ralph <nt_consulting64@yahoo.net> writes:
> On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote:
[...]
>>
>>     You encountered "ANSI style" compilers in the "early 80s?" Six,
>>seven, eight years before the Standard became final?  That's some
>>pretty impressive tea-leaf reading ...
>>
>
> I can appreciate your disbelief especially if one might be used to
> today's environment where the usual process is to develop a "standard"
> and then sit back and watch various vendors move to support the new
> standard.
>
> Such was not the case with C. In computer-years an official 'standard'
> was a long, long time coming. I started using C in 1977 (a year before
> they published the book. <g>) There wasn't a 'Standard' till 1986.
> That was almost 10 years since I started, and ~15 years after it was
> invented.
>
> Do you seriously believe the vendors sat still all that time waiting?

The first ANSI C standard was issued in 1989, not 1986.  Are you
referring to something else that happened in 1986?

I know that the C community was eager to see the new ANSI C standard,
and that part of were implemented before the standard itself was
released.  I don't have a clear idea of what the time scale was.

[...]

> The "-noalias" option was one of the latter ideas. Don't know if I
> ever used a compiler that offered that keyword. I only know I never
> used it. I vaguely remember it as an optimizing option, but believe it
> applied to whole code blocks not to any one variable.

We're not talking about a "-noalias" option.  Early drafts
of the ANSI C standard include a "noalias" keyword.  (I think
C99's "restrict" keyword is a redesigned version of the concept.)
Dennis Ritchie posted his opinion of it in this newsgroup in March
1988 <http://www.lysator.liu.se/c/dmr-on-noalias.html>:

    Noalias must go.  This is non-negotiable.

    It must not be reworded, reformulated or reinvented.  The draft's
    description is badly flawed, but that is not the problem.
    The concept is wrong from start to finish.  It negates
    every brave promise X3J11 ever made about codifying existing
    practices, preserving the existing body of code, and keeping
    (dare I say it?) `the spirit of C.'

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14499

Keith Thompson <kst-u@mib.org> writes:

> ralph <nt_consulting64@yahoo.net> writes:
>> On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
>> <esosman@ieee-dot-org.invalid> wrote:
> [...]
>>>
>>>     You encountered "ANSI style" compilers in the "early 80s?" Six,
>>>seven, eight years before the Standard became final?  That's some
>>>pretty impressive tea-leaf reading ...
>>>
>>
>> I can appreciate your disbelief especially if one might be used to
>> today's environment where the usual process is to develop a "standard"
>> and then sit back and watch various vendors move to support the new
>> standard.
>>
>> Such was not the case with C. In computer-years an official 'standard'
>> was a long, long time coming. I started using C in 1977 (a year before
>> they published the book. <g>) There wasn't a 'Standard' till 1986.
>> That was almost 10 years since I started, and ~15 years after it was
>> invented.
>>
>> Do you seriously believe the vendors sat still all that time waiting?
>
> The first ANSI C standard was issued in 1989, not 1986.  Are you
> referring to something else that happened in 1986?

Several websites refer to a Draft Proposed Standard issued sometime
around 1985/86 intended to gave implementers a "heads up".  The only one
I can recall was a sort of final draft issued in 1988, after noalias was
nixed.  If there was a widely distributed draft in 85/86 it would be
very interesting see it.

> I know that the C community was eager to see the new ANSI C standard,
> and that part of were implemented before the standard itself was
> released.  I don't have a clear idea of what the time scale was.

I seem to recall K&R saying that the code in K&R II was tested using
cfront (early C++) because an ANSI compiler was not available at the
time (probably 1987 since the book came out in 1988).

Maybe they were unaware of compilers that Ralf was aware of in the PC
world.  Of course, no 1985 compiler can be "ANSI C" in the technical
sense, but as a result of good guessing and guidance from having people
on the committee it's just possible they exactly anticipated the
eventual standard.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14501

On Monday, December 12, 2011 11:00:25 PM UTC+8, Ben Bacarisse wrote:
> Keith Thompson <ks...@mib.org> writes:
> 
> > ralph <nt_cons...@yahoo.net> writes:
> >> On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
> >> <esosman@ieee-dot-org.invalid> wrote:
> > [...]
> >>>
> >>>     You encountered "ANSI style" compilers in the "early 80s?" Six,
> >>>seven, eight years before the Standard became final?  That's some
> >>>pretty impressive tea-leaf reading ...
> >>>
> >>
> >> I can appreciate your disbelief especially if one might be used to
> >> today's environment where the usual process is to develop a "standard"
> >> and then sit back and watch various vendors move to support the new
> >> standard.
> >>
> >> Such was not the case with C. In computer-years an official 'standard'
> >> was a long, long time coming. I started using C in 1977 (a year before
> >> they published the book. <g>) There wasn't a 'Standard' till 1986.
> >> That was almost 10 years since I started, and ~15 years after it was
> >> invented.
> >>
> >> Do you seriously believe the vendors sat still all that time waiting?
> >
> > The first ANSI C standard was issued in 1989, not 1986.  Are you
> > referring to something else that happened in 1986?
> 
> Several websites refer to a Draft Proposed Standard issued sometime
> around 1985/86 intended to gave implementers a "heads up".  The only one
> I can recall was a sort of final draft issued in 1988, after noalias was
> nixed.  If there was a widely distributed draft in 85/86 it would be
> very interesting see it.
> 
> > I know that the C community was eager to see the new ANSI C standard,
> > and that part of were implemented before the standard itself was
> > released.  I don't have a clear idea of what the time scale was.
> 
> I seem to recall K&R saying that the code in K&R II was tested using
> cfront (early C++) because an ANSI compiler was not available at the
> time (probably 1987 since the book came out in 1988).
> 
> Maybe they were unaware of compilers that Ralf was aware of in the PC
> world.  Of course, no 1985 compiler can be "ANSI C" in the technical
> sense, but as a result of good guessing and guidance from having people
> on the committee it's just possible they exactly anticipated the
> eventual standard.
> 
> <snip>
> -- 
> Ben.

That was the Pascal and Fortran era in 198x. 
There are p2c and f2c available, thus a lot people just switched programming 
in C. 

But nowadays the 3rd generation of programming language is somewhat
not going anywhere in developing artificial intelligent systems. 
  

[toc] | [prev] | [next] | [standalone]

#14549

On Dec 12, 3:18 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> On Monday, December 12, 2011 11:00:25 PM UTC+8, Ben Bacarisse wrote:
> > Keith Thompson <ks...@mib.org> writes:
> > > ralph <nt_cons...@yahoo.net> writes:
> > >> On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
> > >> <esos...@ieee-dot-org.invalid> wrote:

<snip>

> > > I know that the C community was eager to see the new ANSI C standard,
> > > and that part of were implemented before the standard itself was
> > > released.  I don't have a clear idea of what the time scale was.
>
> > I seem to recall K&R saying that the code in K&R II was tested using
> > cfront (early C++) because an ANSI compiler was not available at the
> > time (probably 1987 since the book came out in 1988).
>
> > Maybe they were unaware of compilers that Ralf was aware of in the PC
> > world.  Of course, no 1985 compiler can be "ANSI C" in the technical
> > sense, but as a result of good guessing and guidance from having people
> > on the committee it's just possible they exactly anticipated the
> > eventual standard.
>
> That was the Pascal and Fortran era in 198x.
> There are p2c and f2c available, thus a lot people just switched programming
> in C.

I don't think p2c and f2c had much influence (I was looking for
CORAL66toc myself)

> But nowadays the 3rd generation of programming language[s]

how do you count generations?

1. FORTRAN, COBOL, ALGOL, LISP
2. Pascal, Occam, Ada, C, C++
3. Java, Perl, Python, Ruby, C#

where do Scheme, Snobol, Haskell, Prolog go?

> is somewhat
> not going anywhere in developing artificial intelligent systems.

was that a goal of Java or Ruby? Or Pascal or FORTRAN?

Another way to count generations is

1. patch panels and valves
2. machine code
3. Fortran (and everything else including Java)
4. Cobol code generators (where are they now?)
5. That Japanese project to write everything in Prolog that no one
remembers now.

[toc] | [prev] | [next] | [standalone]

#14560

On Tuesday, December 13, 2011 4:55:40 PM UTC+8, Nick Keighley wrote:
> On Dec 12, 3:18 pm, 88888 Dihedral <dihedr...@googlemail.com>
> wrote:
> > On Monday, December 12, 2011 11:00:25 PM UTC+8, Ben Bacarisse wrote:
> > > Keith Thompson <ks...@mib.org> writes:
> > > > ralph <nt_co...@yahoo.net> writes:
> > > >> On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
> > > >> <esos...@ieee-dot-org.invalid> wrote:
> 
> <snip>
> 
> > > > I know that the C community was eager to see the new ANSI C standard,
> > > > and that part of were implemented before the standard itself was
> > > > released.  I don't have a clear idea of what the time scale was.
> >
> > > I seem to recall K&R saying that the code in K&R II was tested using
> > > cfront (early C++) because an ANSI compiler was not available at the
> > > time (probably 1987 since the book came out in 1988).
> >
> > > Maybe they were unaware of compilers that Ralf was aware of in the PC
> > > world.  Of course, no 1985 compiler can be "ANSI C" in the technical
> > > sense, but as a result of good guessing and guidance from having people
> > > on the committee it's just possible they exactly anticipated the
> > > eventual standard.
> >
> > That was the Pascal and Fortran era in 198x.
> > There are p2c and f2c available, thus a lot people just switched programming
> > in C.
> 
> I don't think p2c and f2c had much influence (I was looking for
> CORAL66toc myself)
> 
> > But nowadays the 3rd generation of programming language[s]
> 
> how do you count generations?
> 
> 1. FORTRAN, COBOL, ALGOL, LISP
> 2. Pascal, Occam, Ada, C, C++
> 3. Java, Perl, Python, Ruby, C#
> 

1st generation: Just pure machine instructions without any macro or library 
or pseudo instructions. This is somewhat like the relay era long time ago. 

2nd generation: assembler with enhanced tools 

3rd generation: algol family, basic, fortran, pascal, c .....  
 // modular and structure with algorithms 

4th: forth, c++, object pascal, lisp // object oriented  

5th: python, ruby, erlang, perl..... //generic, object, system level   

This is a personal classification of various computer languages. 

> where do Scheme, Snobol, Haskell, Prolog go?

4-6 gen mixed, some languages were just experiments and were not popular 
enough to gain millions of users

[toc] | [prev] | [next] | [standalone]

#14503

On Mon, 12 Dec 2011 15:00:25 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Keith Thompson <kst-u@mib.org> writes:
>
>> ralph <nt_consulting64@yahoo.net> writes:
>>> On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
>>> <esosman@ieee-dot-org.invalid> wrote:
>> [...]
>>>>
>>>>     You encountered "ANSI style" compilers in the "early 80s?" Six,
>>>>seven, eight years before the Standard became final?  That's some
>>>>pretty impressive tea-leaf reading ...
>>>>
>>>
>>> I can appreciate your disbelief especially if one might be used to
>>> today's environment where the usual process is to develop a "standard"
>>> and then sit back and watch various vendors move to support the new
>>> standard.
>>>
>>> Such was not the case with C. In computer-years an official 'standard'
>>> was a long, long time coming. I started using C in 1977 (a year before
>>> they published the book. <g>) There wasn't a 'Standard' till 1986.
>>> That was almost 10 years since I started, and ~15 years after it was
>>> invented.
>>>
>>> Do you seriously believe the vendors sat still all that time waiting?
>>
>> The first ANSI C standard was issued in 1989, not 1986.  Are you
>> referring to something else that happened in 1986?
>
>Several websites refer to a Draft Proposed Standard issued sometime
>around 1985/86 intended to gave implementers a "heads up".  The only one
>I can recall was a sort of final draft issued in 1988, after noalias was
>nixed.  If there was a widely distributed draft in 85/86 it would be
>very interesting see it.
>

I attended a local committee meeting I believe in 1986. Might have
been 1987 <???>. (Ghod I hate getting old. <g>) At that time I paid, I
think, ~$50 for a cheap bound "draft". The youngsters might find it
hard to believe amount of paper we used back then. Digital media was
rare, and often in some obscure format when it was available.  <g>

I'm such a pack rat I might still have it boxed up someplace, I'll go
and try to find it.

>> I know that the C community was eager to see the new ANSI C standard,
>> and that part of were implemented before the standard itself was
>> released.  I don't have a clear idea of what the time scale was.
>
>I seem to recall K&R saying that the code in K&R II was tested using
>cfront (early C++) because an ANSI compiler was not available at the
>time (probably 1987 since the book came out in 1988).
>
>Maybe they were unaware of compilers that Ralf was aware of in the PC
>world.  Of course, no 1985 compiler can be "ANSI C" in the technical
>sense, but as a result of good guessing and guidance from having people
>on the committee it's just possible they exactly anticipated the
>eventual standard.
>
><snip>

Well we were talking about "ANSI style" declarations and prototypes. I
know those features were available with MSC 3.0, the compiler was
generally considered "ANSI compatible", and was in wide-use by 1985.
But I agree with you - there is absolutely NO way it could have been
fully C89 compilant. There were still minor compliancy issues with MSC
5/6 and they were released AFTER C89.

[I remember the discussions and complaints, but not the details. As
I've already noted - I'm no language lawyer. Nor do I have much
patience for those who quarrel over which IMHO is minutia. <g>]

I don't know what particular ANSI features K&R might have considered
as 'unavailable'. But given the climate of the day and the target
audience, I'm positive NO limited platform compiler would have been
considered "suitable" for such a book. 

-ralph

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web