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 1 of 3  [1] 2 3  Next page →

#14444 — When did K&R function declarations become obsolete?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

[toc] | [next] | [standalone]

#14446

On 2011-12-10, 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.

These declarations are still a feature of the 1999 C language, but marked as
obsolescent ISO 9899:1999:

6.11.7 Function definitions

1 The use of function definitions with separate parameter identifier and
  declaration lists (not prototype-format parameter type and identifier
  declarators) is an obsolescent feature.

(If you want to know about the current draft status of this, Google it up;
I dont' know.)

> Presumably these declarations are still widely used in compiler validation
> suites but nowhere else.

They likely appear in some nonzero but impossible to quantify amount of legacy
code.

Some open source programs still use old style definitions, coupled with
prototype declarations.

E.g.:

   int func PROTO(( char *, int ));

   /* ... */

   int func(a, b)
   char *a;
   int b;
   {
      /*...*/
   }

Are these programs rare? In some sense, yes, but in fact we do not have to go
far to find an example. 

For instance, oh, the GNU C Library (glibc):

http://sourceware.org/git/?p=glibc.git;a=blob;f=io/open.c

Snippet retrieved Sat Dec 10 10:40:55 PST 2011:

/* Open FILE with access OFLAG.  If OFLAG includes O_CREAT,
   a third argument is the file protection.  */
int
__open (file, oflag)
     const char *file;
     int oflag;
{
  int mode;

  if (file == NULL)
    {
      __set_errno (EINVAL);
      return -1;
    }

> Approximately when did they become obsolete, i.e. not used at all for new
> code?

This is impossible to know, without a crystal ball that peers into
what everyone on the planet is coding.

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

#14447

The _fastcall, _cdecl, _pascall were used everywhere. 

Do you really know how c functions are called  in the run time ?

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

#14448

On 12/11/11 07:40 AM, 88888 Dihedral wrote:
> The _fastcall, _cdecl, _pascall were used everywhere.

The what?

> Do you really know how c functions are called  in the run time ?

What on Earth is this nonsense in reply to?

-- 
Ian Collins

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

#14449

88888 Dihedral <dihedral88888@googlemail.com> writes:

> The _fastcall, _cdecl, _pascall were used everywhere. 

...in Windows and perhaps MS-DOS code and nowhere else, and are
completely orthogonal to the transition from K&R to
prototype-style function declarations.
-- 
Ben Pfaff 
http://benpfaff.org

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

#14453

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?

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. But then I did
programming nearly exclussively under UNIX, things might be diffe-
rent for platforms were "modern" compilers weren't available that
easily. And, of course, people having to cater for the very smal-
lest common denominator (i.e. systems were no C89 compliant com-
piler exists) still have to use them in one form or another (as
the example Kaz came up with might be an example for).

If this is for the emacs C mode then, since the standard still
requires support for the "old way" (even though it might be de-
clared as obsolete) I would think it prudent not to throw it
out completely.
                               Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#14491

Jens Thoms Toerring <jt@toerring.de> wrote:
> 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?

> 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. But then I did
> programming nearly exclussively under UNIX, things might be diffe-
> rent for platforms where "modern" compilers weren't available that
> easily. And, of course, people having to cater for the very smal-
> lest common denominator (i.e. systems were no C89 compliant com-
> piler exists) still have to use them in one form or another (as
> the example Kaz came up with might be an example for).

I think 1995 sounds about right.

> If this is for the emacs C mode then, since the standard still
> requires support for the "old way" (even though it might be de-
> clared as obsolete) I would think it prudent not to throw it
> out completely.

Don't worry, there's no chance of that.  :-)  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.

>                               Regards, Jens

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#14492

On Monday, December 12, 2011 7:29:09 PM UTC+8, Alan Mackenzie wrote:
> Jens Thoms Toerring <j...@toerring.de> 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. But then I did
> > programming nearly exclussively under UNIX, things might be diffe-
> > rent for platforms where "modern" compilers weren't available that
> > easily. And, of course, people having to cater for the very smal-
> > lest common denominator (i.e. systems were no C89 compliant com-
> > piler exists) still have to use them in one form or another (as
> > the example Kaz came up with might be an example for).
> 
> I think 1995 sounds about right.
> 
> > If this is for the emacs C mode then, since the standard still
> > requires support for the "old way" (even though it might be de-
> > clared as obsolete) I would think it prudent not to throw it
> > out completely.
> 
> Don't worry, there's no chance of that.  :-)  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.
> 
> >                               Regards, Jens
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).

In a standard C compiler, a line can be very very  long and the  number of 
arguments allowed in a C function is  nearly free style. 

OK, this is a good environment for those  who want to write  obfuscated 
programs  easily. 




  

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

#14500

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.
You description hints at some hard to resolve ambiguity with old-style
function declarations.

-- 
Ben.

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

#14554

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.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#14557

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.

-- 
Ben.

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

#14559

"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'?

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.


-- 
poncho

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

#14562

On Tue, 13 Dec 2011 10:17:53 -0500, "Scott Fluhrer"
<sfluhrer@ix.netcom.com> wrote:

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

It wasn't just the compiler 'parser' either. 'Standard C' also made it
much easier to work with code browsers, formatters, and
static-checkers. Initiallly home-grown, but quickly supplemented with
external commercial utilities. 

-ralph

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

#14563

On 2011-12-13, ralph <nt_consulting64@yahoo.net> wrote:
> On Tue, 13 Dec 2011 10:17:53 -0500, "Scott Fluhrer"
><sfluhrer@ix.netcom.com> wrote:
>
>> ....  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.
>
> It wasn't just the compiler 'parser' either. 'Standard C' also made it
> much easier to work with code browsers, formatters, and
> static-checkers. Initiallly home-grown, but quickly supplemented with
> external commercial utilities. 

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

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

#14573

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

>On 2011-12-13, ralph <nt_consulting64@yahoo.net> wrote:
>> On Tue, 13 Dec 2011 10:17:53 -0500, "Scott Fluhrer"
>><sfluhrer@ix.netcom.com> wrote:
>>
>>> ....  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.
>>
>> It wasn't just the compiler 'parser' either. 'Standard C' also made it
>> much easier to work with code browsers, formatters, and
>> static-checkers. Initiallly home-grown, but quickly supplemented with
>> external commercial utilities. 
>
>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.

-ralph

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

#14574

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:
>
>>On 2011-12-13, ralph <nt_consulting64@yahoo.net> wrote:
>>> On Tue, 13 Dec 2011 10:17:53 -0500, "Scott Fluhrer"
>>><sfluhrer@ix.netcom.com> wrote:
>>>
>>>> ....  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.
>>>
>>> It wasn't just the compiler 'parser' either. 'Standard C' also made it
>>> much easier to work with code browsers, formatters, and
>>> static-checkers. Initiallly home-grown, but quickly supplemented with
>>> external commercial utilities. 
>>
>>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.

The type info is there. Prototypes are juts a crutch for type checking,
which allows C to retain the model of translation taking place without
any global knowledge about the program, other than what is brought in 
via #include. They are a quick and dirty way to almost achieve support
for modularity in the language with the assistance of a textual preprocessor,
nothing more.

Code cross referencing and browsing tools cannot reasonably follow the same
limitation of dealing with one translation unit.

Do prototypes make it easier to make such tools? I don't see how.  If you write
a great tool that cross-references material from K&R C code bases, it is extra
work to adapt that tool to handle prototypes, even just to recognize and ignore
them.

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

#14575

On 2011-12-13, Kaz Kylheku <kaz@kylheku.com> wrote:
> 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)
>   {

It's harder for me on reading it.  It's also quite a lot harder in the
case where I'm looking at headers, and the choice is between:

	extern int foo();
	extern int foo(char *, double);

> The type info is there. Prototypes are juts a crutch for type checking,
> which allows C to retain the model of translation taking place without
> any global knowledge about the program, other than what is brought in 
> via #include. They are a quick and dirty way to almost achieve support
> for modularity in the language with the assistance of a textual preprocessor,
> nothing more.

They're good enough modularity for me to use binaries for source code that's
never been on my machine, which is good for me.

> Do prototypes make it easier to make such tools?

Well, they certainly do in the fairly common case where there's a reason
for which you have headers but not the complete source.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14576

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?

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

#14579

On 2011-12-13, Joe keane <jgk@panix.com> wrote:
> 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 mostly agree with this.  If it weren't for the "default promotions"
applying to old-style definitions, I might well use them by preference.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14589

On 2011-12-13, Seebs <usenet-nospam@seebs.net> wrote:
> On 2011-12-13, Joe keane <jgk@panix.com> wrote:
>> 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 mostly agree with this.  If it weren't for the "default promotions"
> applying to old-style definitions, I might well use them by preference.

Obsolecence of a feature can lead to a semantics change to the old syntax,
rather than removal.

I.e. it could simply be required, one day, that

  void x(f)
  float f;
  {
  }

now means exactly the same thing as:

  void x(float f)
  {
  }

and the syntax is no longer obsolescent, just the old semantics.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web