When did K&R function declarations become obsolete?

Discussion in 'C Programming' started by Alan Mackenzie, Dec 10, 2011.

  1. 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).
     
    Alan Mackenzie, Dec 10, 2011
    #1
    1. Advertising

  2. The _fastcall, _cdecl, _pascall were used everywhere.

    Do you really know how c functions are called in the run time ?
     
    88888 Dihedral, Dec 10, 2011
    #2
    1. Advertising

  3. Alan Mackenzie

    Kaz Kylheku Guest

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


    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.
     
    Kaz Kylheku, Dec 10, 2011
    #3
  4. Alan Mackenzie

    Ian Collins Guest

    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
     
    Ian Collins, Dec 10, 2011
    #4
  5. Alan Mackenzie

    Ben Pfaff Guest

    88888 Dihedral <> 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
     
    Ben Pfaff, Dec 10, 2011
    #5
  6. 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?


    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 ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Dec 10, 2011
    #6
  7. Alan Mackenzie <> 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
    <>,
    <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) <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"
     
    Keith Thompson, Dec 10, 2011
    #7
  8. 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
     
    Ralph Spitzner, Dec 11, 2011
    #8
  9. Alan Mackenzie

    ralph Guest

    On Sat, 10 Dec 2011 18:23:19 +0000 (UTC), 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.]


    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
     
    ralph, Dec 11, 2011
    #9
  10. Keith Thompson <> 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) <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"
     
    Keith Thompson, Dec 11, 2011
    #10
  11. Ralph Spitzner <> 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) <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"
     
    Keith Thompson, Dec 11, 2011
    #11
  12. ralph <> writes:

    > On Sat, 10 Dec 2011 18:23:19 +0000 (UTC), 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.]

    >
    > 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.
     
    Ben Bacarisse, Dec 11, 2011
    #12
  13. Alan Mackenzie

    Eric Sosman Guest

    On 12/11/2011 7:56 AM, Ben Bacarisse wrote:
    > ralph<> 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
    d
     
    Eric Sosman, Dec 11, 2011
    #13
  14. Alan Mackenzie

    James Kuyper Guest

    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
     
    James Kuyper, Dec 11, 2011
    #14
  15. 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!
     
    88888 Dihedral, Dec 11, 2011
    #15
  16. Alan Mackenzie

    ralph Guest

    On Sun, 11 Dec 2011 12:56:53 +0000, Ben Bacarisse
    <> wrote:

    >ralph <> writes:
    >
    >> On Sat, 10 Dec 2011 18:23:19 +0000 (UTC), 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.]

    >>
    >> 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
     
    ralph, Dec 11, 2011
    #16
  17. Alan Mackenzie

    ralph Guest

    On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
    <> wrote:

    >On 12/11/2011 7:56 AM, Ben Bacarisse wrote:
    >> ralph<> 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
     
    ralph, Dec 12, 2011
    #17
  18. ralph <> writes:
    > On Sun, 11 Dec 2011 09:11:33 -0500, Eric Sosman
    > <> 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) <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"
     
    Keith Thompson, Dec 12, 2011
    #18
  19. 88888 Dihedral <> 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) <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"
     
    Keith Thompson, Dec 12, 2011
    #19
  20. Jens Thoms Toerring <> wrote:
    > 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?


    > 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).
     
    Alan Mackenzie, Dec 12, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SB

    Did I buy obsolete book?

    SB, Mar 19, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    428
    Jon Skeet [C# MVP]
    Mar 19, 2006
  2. Douglas
    Replies:
    2
    Views:
    332
    Herbert Rosenau
    Jul 5, 2004
  3. ZSP747
    Replies:
    0
    Views:
    414
    ZSP747
    Dec 25, 2005
  4. Tricky
    Replies:
    11
    Views:
    2,554
    Tricky
    Jan 19, 2009
  5. Daniel Waite
    Replies:
    2
    Views:
    228
    Daniel Waite
    May 2, 2008
Loading...

Share This Page