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 3 of 3 — ← Prev page 1 2 [3]

#14504

On Mon, 12 Dec 2011 00:05:38 -0800, Keith Thompson <kst-u@mib.org>
wrote:

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

Yeah, that was a bit of misdirection on my side. Thanks for catching
that. I was trying to piece together a time scale in my mind while I
was typing. <g>

I remembered attending a local "J Committee" meeting in 1986 (and two
more after - 87???), and was going to offer the fact that we were
predominately arguing over what current implementations should appear
in the eventual standard as evidence that much of "ANSI stuff" was
already in common use. But my memory is just too foggy. Can't supply
vendor names or versions (except for Microsoft) so I decided to skip
going down that road. But I had "1986" stuck in my brain as the year
when we started thinking about "ANSI".

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

Yes I know the noalias suggestion was a keyword. The original question
was if I remembered ever using that keyword. My answer was no, but
vaguely remember there being the compiler option back then.

Ritchie sums it up for most of the fights and distinctly illustrates
what I considered emphasizing in my previous post - most of what
eventually became "standardized" in the ANSI Standard was already in
common "existing practice" before C89. 

At least that is how I remember it, but seeing Mr. Sosman's and Mr.
Becarisse's posts it is now obvious that was not that "common" for
everyone and has been rather enlightening. Previous to their posts I
would have scoffed at the notion that any shop was still adhering to a
"K&R C Standard" by 1990. Can't do that now. <g>

-ralph

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

#14520

In article <vi6ce7l20tfe9jcr2ttjqkcceg3sk1hngp@4ax.com>,
ralph  <nt_consulting64@yahoo.net> wrote:

>But I had "1986" stuck in my brain as the year when we started thinking
>about "ANSI".

Sounds about right, where everyone agreed on the meaning and most
current compilers accept it [of course you can find old/not updated
compilers].

Add another ten years for it to be more prevalent.

Is it similar for:

definitely have 'void'
can pass and return 'struct'

?

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

#14530

On 12/12/2011 4:57 PM, Joe keane wrote:
> In article<vi6ce7l20tfe9jcr2ttjqkcceg3sk1hngp@4ax.com>,
> ralph<nt_consulting64@yahoo.net>  wrote:
>
>> But I had "1986" stuck in my brain as the year when we started thinking
>> about "ANSI".
>
> Sounds about right, where everyone agreed on the meaning and most
> current compilers accept it [of course you can find old/not updated
> compilers].

     There was, of course, a risk in jumping the gun: You might build
a feature in accordance with a working draft, only to see the final
Standard make changes.  Something of this sort certainly happened with
C99: The gcc folks had implemented some features that the C99 Standard
chose to do differently.

> Add another ten years for it to be more prevalent.
>
> Is it similar for:
>
> definitely have 'void'

     Speaking for myself, I didn't see `void' widely used until after
ANSI was adopted.  But then, the code I was involved with at the time
was running on five platforms with ports in progress for a sixth and
seventh; we didn't want to adopt anything new until we were sure it
would work on all our targets.  Uptake may have been more rapid in
monoculture environments.

     `void*' (as opposed to plain `void') started to appear in our
code fairly early, because it was easy to `typedef char void;' for
compilers that didn't have it.  True, the resulting `char*' would
not convert silently to other pointer types -- but the compilers
that didn't have `void*' already required casts anyhow, so the ruse
was "mostly harmless."

> can pass and return 'struct'

     Again speaking for myself, we did this freely in pre-ANSI days;
the capability had come into general use not long after the K&R book.
We used enums freely, too (they're also absent from K&R).

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

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

#14485

On Sun, 11 Dec 2011 12:56:53 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

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

I have no doubt everyone's experience would vary. While predominately
working with UNIX "my" boxes were mostly of the "micro" variety, I
also quickly jumped on the PC bandwagon. As I noted the Microsoft C
compiler was "ANSI-compatible" by 1985. I can't remember a single
mainstream PC compiler that wasn't by then.

Most of the UNIX shops I worked with had purchased "development
packages" which I'm sure had superior features to the "generic" C
compilers that came with the O/S.

So yes in "my world" *everyone* had a prototype-aware C compiler by
1985.

-ralph

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

#14482

On 12/10/2011 01:23 PM, 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.
> 
> 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.]

For me personally, non-prototype declarations became (almost) obsolete
as soon as I learned about prototypes, which was shortly after the C
standard was first published. However, many people write code to
standards which require portability to compilers that pre-date the C
standard, even though their code no longer needs to be ported to such
compilers, and hasn't needed such porting for a decade or more.
Therefore, I doubt that they have yet become obsolete in the sense that
you define: "not used at all for new code".

Also, there's still one point where non-prototype function declarations
are useful. Try to declare a prototype for a function taking, as an
argument, a pointer to a function of the SAME type. You'll quickly
discover that the declaration recurses infinitely. Somewhere along the
way, you have to terminate it. There's a number of ways to terminate it,
but the simplest is to use a non-prototype declaration that leaves the
number and type of the parameters unspecified. Other methods, in
principle, run into type compatibility issues if the pointer is actually
used to call a function whose definition uses the same prototype.
-- 
James Kuyper

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

#14483

On Sunday, December 11, 2011 10:17:25 PM UTC+8, James Kuyper wrote:
> On 12/10/2011 01:23 PM, 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.
> > 
> > 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.]
> 
> For me personally, non-prototype declarations became (almost) obsolete
> as soon as I learned about prototypes, which was shortly after the C
> standard was first published. However, many people write code to
> standards which require portability to compilers that pre-date the C
> standard, even though their code no longer needs to be ported to such
> compilers, and hasn't needed such porting for a decade or more.
> Therefore, I doubt that they have yet become obsolete in the sense that
> you define: "not used at all for new code".
> 
> Also, there's still one point where non-prototype function declarations
> are useful. Try to declare a prototype for a function taking, as an
> argument, a pointer to a function of the SAME type. You'll quickly
> discover that the declaration recurses infinitely. Somewhere along the
> way, you have to terminate it. There's a number of ways to terminate it,
> but the simplest is to use a non-prototype declaration that leaves the
> number and type of the parameters unspecified. Other methods, in
> principle, run into type compatibility issues if the pointer is actually
> used to call a function whose definition uses the same prototype.
> -- 
> James Kuyper

A portable C programs in many platforms without noticing that a novice programmer only produces a c program  would be  so buggy even 
in additions or multiplications in counting a  buffer size to malloc
or not noticing the choked qsort?

Forget that idea!

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

#14489

88888 Dihedral <dihedral88888@googlemail.com> writes:
> A portable C programs in many platforms without noticing that a novice
> programmer only produces a c program would be so buggy even in
> additions or multiplications in counting a buffer size to malloc or
> not noticing the choked qsort?
>
> Forget that idea!

http://en.wikipedia.org/wiki/Word_salad

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

#14493

James Kuyper <jameskuyper@verizon.net> wrote:
> On 12/10/2011 01:23 PM, 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.
 
>> 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.]

> For me personally, non-prototype declarations became (almost) obsolete
> as soon as I learned about prototypes, which was shortly after the C
> standard was first published. However, many people write code to
> standards which require portability to compilers that pre-date the C
> standard, even though their code no longer needs to be ported to such
> compilers, and hasn't needed such porting for a decade or more.
> Therefore, I doubt that they have yet become obsolete in the sense that
> you define: "not used at all for new code".

Interesting!  I don't think I'd like to work in a shop like that, though.

> Also, there's still one point where non-prototype function declarations
> are useful. Try to declare a prototype for a function taking, as an
> argument, a pointer to a function of the SAME type. You'll quickly
> discover that the declaration recurses infinitely.

A fine academic exercise, sure, but is there any practical use of such a
declaration?  It sounds like something you'd really want a functional
programming language to do.

> Somewhere along the way, you have to terminate it. There's a number of
> ways to terminate it, but the simplest is to use a non-prototype
> declaration that leaves the number and type of the parameters
> unspecified.

Won't the judicious use of "void *" for the parameter do the trick?

> Other methods, in principle, run into type compatibility
> issues if the pointer is actually used to call a function whose
> definition uses the same prototype.

Thanks for this idea.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#14495

On 12/12/2011 06:59 AM, Alan Mackenzie wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
...
>> standard was first published. However, many people write code to
>> standards which require portability to compilers that pre-date the C
>> standard, even though their code no longer needs to be ported to such
>> compilers, and hasn't needed such porting for a decade or more.
>> Therefore, I doubt that they have yet become obsolete in the sense that
>> you define: "not used at all for new code".
> 
> Interesting!  I don't think I'd like to work in a shop like that, though.

Me neither. I'm an early adopter (but unlike ralph, I'm not a
pre-adopter). I adopted the new features of C90 as soon as I knew I
could use a compiler that supported them. I would have done the same for
C99, if the coding standards imposed on our project by our client
allowed it - which they (still!) do not.

>> Also, there's still one point where non-prototype function declarations
>> are useful. Try to declare a prototype for a function taking, as an
>> argument, a pointer to a function of the SAME type. You'll quickly
>> discover that the declaration recurses infinitely.
> 
> A fine academic exercise, sure, but is there any practical use of such a
> declaration?  It sounds like something you'd really want a functional
> programming language to do.

I first ran into this issue in the context of signal handlers, but I
don't remember the details well enough to allow you to evaluate the
practicality of the design. It was a standard library (not the C
standard library) function heavily used by a great many other people, so
I presume it wasn't just an academic exercise for them. However, I've
never written programs for which signal handling was needed, which is
why I don't remember the details.

There's a similar issue with declaring a function that returns a pointer
to a function of the same type.

>> Somewhere along the way, you have to terminate it. There's a number of
>> ways to terminate it, but the simplest is to use a non-prototype
>> declaration that leaves the number and type of the parameters
>> unspecified.
> 
> Won't the judicious use of "void *" for the parameter do the trick?

No, void* and function pointer types are not compatible.
-- 
James Kuyper

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

#14509

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/12/2011 06:59 AM, Alan Mackenzie wrote:
>> James Kuyper <jameskuyper@verizon.net> wrote:
[...]
>>> Also, there's still one point where non-prototype function declarations
>>> are useful. Try to declare a prototype for a function taking, as an
>>> argument, a pointer to a function of the SAME type. You'll quickly
>>> discover that the declaration recurses infinitely.
[...]
>>> Somewhere along the way, you have to terminate it. There's a number of
>>> ways to terminate it, but the simplest is to use a non-prototype
>>> declaration that leaves the number and type of the parameters
>>> unspecified.
>> 
>> Won't the judicious use of "void *" for the parameter do the trick?
>
> No, void* and function pointer types are not compatible.

But the language guarantees that converting any function pointer 
to another pointer-to-function type and back again yields the original
pointer.  That means you can use *any* pointer-to-function type (the
simplest is "void (*)(void)") as a generic pointer-to-function type.

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

#14532

On 12/12/2011 2:59 PM, Keith Thompson wrote:
> James Kuyper<jameskuyper@verizon.net>  writes:
>> No, void* and function pointer types are not compatible.
>
> But the language guarantees that converting any function pointer
> to another pointer-to-function type and back again yields the original
> pointer.  That means you can use *any* pointer-to-function type (the
> simplest is "void (*)(void)") as a generic pointer-to-function type.

     "void (*)()" is even simpler -- which gets us back to the
thread's original topic ;-)

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

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

#14535

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 12/12/2011 2:59 PM, Keith Thompson wrote:
>> James Kuyper<jameskuyper@verizon.net>  writes:
>>> No, void* and function pointer types are not compatible.
>>
>> But the language guarantees that converting any function pointer
>> to another pointer-to-function type and back again yields the original
>> pointer.  That means you can use *any* pointer-to-function type (the
>> simplest is "void (*)(void)") as a generic pointer-to-function type.
>
>      "void (*)()" is even simpler -- which gets us back to the
> thread's original topic ;-)

It's shorter by one token and 4 letters.  But I'd say that "pointer to
function with no parameters and returning no result" is *conceptually*
simpler than "pointer to function with an unspecified but fixed number
and type(s) of parameter(s) and returning no result".

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

#14496

Alan Mackenzie <acm@muc.de> wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
> > Also, there's still one point where non-prototype function declarations
> > are useful. Try to declare a prototype for a function taking, as an
> > argument, a pointer to a function of the SAME type. You'll quickly
> > discover that the declaration recurses infinitely.
> 
> A fine academic exercise, sure, but is there any practical use of such a
> declaration?  It sounds like something you'd really want a functional
> programming language to do.
> 
> > Somewhere along the way, you have to terminate it. There's a number of
> > ways to terminate it, but the simplest is to use a non-prototype
> > declaration that leaves the number and type of the parameters
> > unspecified.
> 
> Won't the judicious use of "void *" for the parameter do the trick?
> 

Something like:
typedef int (*recfunc_type)(int (*func)(void));

int recfunc(int (*func)(void))
{
  /* ... */
  ((recfunc_type)func)(func);
  /* ... */
}

This should work, as the function pointer is eventually converted to
the correct data type.

-- 
André Gillibert

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

#14497

On Monday, December 12, 2011 8:49:52 PM UTC+8, André Gillibert wrote:
> Alan Mackenzie <a...@muc.de> wrote:
> > James Kuyper <james...@verizon.net> wrote:
> > > Also, there's still one point where non-prototype function declarations
> > > are useful. Try to declare a prototype for a function taking, as an
> > > argument, a pointer to a function of the SAME type. You'll quickly
> > > discover that the declaration recurses infinitely.
> > 
> > A fine academic exercise, sure, but is there any practical use of such a
> > declaration?  It sounds like something you'd really want a functional
> > programming language to do.
> > 
> > > Somewhere along the way, you have to terminate it. There's a number of
> > > ways to terminate it, but the simplest is to use a non-prototype
> > > declaration that leaves the number and type of the parameters
> > > unspecified.
> > 
> > Won't the judicious use of "void *" for the parameter do the trick?
> > 
> 
> Something like:
> typedef int (*recfunc_type)(int (*func)(void));
> 
> int recfunc(int (*func)(void))
> {
>   /* ... */
>   ((recfunc_type)func)(func);
>   /* ... */
> }
> 
> This should work, as the function pointer is eventually converted to
> the correct data type.
> 
> -- 
> André Gillibert

Wrap the input functor to a some other functor.  
I don't use typedef too often. 
Also this will lead to the question: 
If there are failures in using a functor due to some I/O or OS services, 
what error messages can be thrown and what function to catch these kinds of 
failures?  

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

#14498

88888 Dihedral <dihedral88888@googlemail.com> wrote:
> On Monday, December 12, 2011 8:49:52 PM UTC+8, André Gillibert wrote:
> > Alan Mackenzie <a...@muc.de> wrote:
> > > James Kuyper <james...@verizon.net> wrote:
> > > > Also, there's still one point where non-prototype function declarations
> > > > are useful. Try to declare a prototype for a function taking, as an
> > > > argument, a pointer to a function of the SAME type. You'll quickly
> > > > discover that the declaration recurses infinitely.
> > > 
> > > A fine academic exercise, sure, but is there any practical use of such a
> > > declaration?  It sounds like something you'd really want a functional
> > > programming language to do.
> > > 
> > > > Somewhere along the way, you have to terminate it. There's a number of
> > > > ways to terminate it, but the simplest is to use a non-prototype
> > > > declaration that leaves the number and type of the parameters
> > > > unspecified.
> > > 
> > > Won't the judicious use of "void *" for the parameter do the trick?
> > > 
> > 
> > Something like:
> > typedef int (*recfunc_type)(int (*func)(void));
> > 
> > int recfunc(int (*func)(void))
> > {
> >   /* ... */
> >   ((recfunc_type)func)(func);
> >   /* ... */
> > }
> > 
> > This should work, as the function pointer is eventually converted to
> > the correct data type.
> > 
> > -- 
> > André Gillibert
> 
> Wrap the input functor to a some other functor.  
> I don't use typedef too often. 
> Also this will lead to the question: 
> If there are failures in using a functor due to some I/O or OS services, 
> what error messages can be thrown and what function to catch these kinds of 
> failures?  

How does that lead to this question?

-- 
André Gillibert

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

#14502

Alan Mackenzie <acm@muc.de> writes:

> James Kuyper <jameskuyper@verizon.net> wrote:
<snip>
>> Also, there's still one point where non-prototype function declarations
>> are useful. Try to declare a prototype for a function taking, as an
>> argument, a pointer to a function of the SAME type. You'll quickly
>> discover that the declaration recurses infinitely.
>
> A fine academic exercise, sure, but is there any practical use of such a
> declaration?  It sounds like something you'd really want a functional
> programming language to do.

Similar things crop up naturally in some state machine implementations
but It's certainly not common.

>> Somewhere along the way, you have to terminate it. There's a number of
>> ways to terminate it, but the simplest is to use a non-prototype
>> declaration that leaves the number and type of the parameters
>> unspecified.
>
> Won't the judicious use of "void *" for the parameter do the trick?

So will using int, or any other type!  void * does not help directly
(because function pointers don't convert to and from void *) but it
won't hurt.  Unless the parameter can be declared directly, a cast is
needed at the point of call to convert the function pointer, whose type
we have effectively lied about, to the correct type.

Using an old-stlye function pointer type has the advantage of being a
bit clearer:

  int function(int (*fp)(), int);

is less of a lie than simply picking a type for fp's first parameter.
If you use old-style declarations (and definitions) all the way, then
you don't need a cast at all, but you do lose all type-checking.

<snip>
-- 
Ben.

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

#14596

On 12/10/11 10:23 AM, 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.
>
> 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?

They are still used in the GCC source code, probably to ensure that GCC 
can be compiled by a compiler that does not recognize prototypes.  (It 
used to be the case the HP-UX comes with such a compiler, used for 
rebuilding the kernel.)

They are still used in the C code distributed with the Olson timezone 
database.

They are still, regrettably, used in some of the code I help maintain. 
When I've finished modifying a file, there are usually no non-prototype 
functions left, but it takes a long time to get through 20,000 files on 
your own.  Until the mid-90s, there were machines where the compilers 
that were used by the work environments were still pre-standard 
compilers.  Although there were newer compilers with support for 
prototypes, we did not always have those compilers available.

Personally, I have not written a non-prototype function definition 
except for testing purposes since the turn of the millennium, probably 
somewhat earlier.  I started converting my code to prototype notations 
not later than 1996; I partially converted some of my code as early as 
1991, but I then coded with support for both prototype and non-prototype 
function definitions to improve portability.

I still encounter them routinely, and curse the fact that no-one else 
has bothered to convert them.  (There are more or less complete sets of 
headers with prototypes for the functions - so there is normally a 
prototype in scope when the function definition is compiled or the 
called, but not always.)  And one or two benighted individuals have 
produced new K&R functions for consistency with the rest of the file. 
When I find out in time, I have a firm discussion with the individual, 
who usually repents of their aberrant ways.  But too often I don't find 
out about it until some time later.

Just some data points...one person's observations.

Yours,
Jonathan Leffler  <jleffler@earthlink.net>  #include <disclaimer.h>

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

#14598

Jonathan Leffler <jleffler@earthlink.net> writes:
> On 12/10/11 10:23 AM, 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.
>>
>> 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?
>
> They are still used in the GCC source code, probably to ensure that
> GCC can be compiled by a compiler that does not recognize prototypes.
> (It used to be the case the HP-UX comes with such a compiler, used for
> rebuilding the kernel.)

As of gcc 3.4:

     * GCC now requires an ISO C90 (ANSI C89) C compiler to build. K&R C
       compilers will not work.

(quoted from the gcc 4.6.0 NEWS file).  gcc 3.4.0 was released April,
2004; the last 3.4 release, 3.4.6, was March, 2006.  But that doesn't
necessarily mean there aren't still non-prototype declarations.

[...]

> I still encounter them routinely, and curse the fact that no-one else
> has bothered to convert them.  (There are more or less complete sets
> of headers with prototypes for the functions - so there is normally a
> prototype in scope when the function definition is compiled or the
> called, but not always.)  And one or two benighted individuals have
> produced new K&R functions for consistency with the rest of the
> file. When I find out in time, I have a firm discussion with the
> individual, who usually repents of their aberrant ways.  But too often
> I don't find out about it until some time later.

Maintaining existing coding style is *usually* a very good idea.
Prototypes are an unusual case where one style is clearly better than
another one.

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

#14607

On Wednesday, December 14, 2011 6:54:25 PM UTC+8, Keith Thompson wrote:
> Jonathan Leffler <jlef...@earthlink.net> writes:
> > On 12/10/11 10:23 AM, 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.
> >>
> >> 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?
> >
> > They are still used in the GCC source code, probably to ensure that
> > GCC can be compiled by a compiler that does not recognize prototypes.
> > (It used to be the case the HP-UX comes with such a compiler, used for
> > rebuilding the kernel.)
> 
> As of gcc 3.4:
> 
>      * GCC now requires an ISO C90 (ANSI C89) C compiler to build. K&R C
>        compilers will not work.
> 
> (quoted from the gcc 4.6.0 NEWS file).  gcc 3.4.0 was released April,
> 2004; the last 3.4 release, 3.4.6, was March, 2006.  But that doesn't
> necessarily mean there aren't still non-prototype declarations.
> 
> [...]
> 
> > I still encounter them routinely, and curse the fact that no-one else
> > has bothered to convert them.  (There are more or less complete sets
> > of headers with prototypes for the functions - so there is normally a
> > prototype in scope when the function definition is compiled or the
> > called, but not always.)  And one or two benighted individuals have
> > produced new K&R functions for consistency with the rest of the
> > file. When I find out in time, I have a firm discussion with the
> > individual, who usually repents of their aberrant ways.  But too often
> > I don't find out about it until some time later.
> 
> Maintaining existing coding style is *usually* a very good idea.
> Prototypes are an unusual case where one style is clearly better than
> another one.
> 
> -- 
> Keith Thompson (The_Other_Keith) ks...@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"

Unless there won't be new instruction sets of CPU designed to emerge on the world, the old style K&R non-prototyped assembly calling convention won't 
die. 

[toc] | [prev] | [standalone]

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

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

csiph-web