Ambiguous errata solutions for K&R2

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Ioannis Vranos

    Ambiguous errata solutions for K&R2

    In K&R2 errata page
    <http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
    there are some ambiguous errata, for which I propose solutions. Any
    comments are welcome.



    Ambiguous errata (mentioned first) of "The C Programming Language" 2nd
    Edition errata page
    (http://www-db-out.research.bell-labs.../2ediffs.html), and
    proposed solutions that should be added to the errata page exactly as
    they appear:


    1. "119-121(§5.11): The qsort discussion needs recasting in several ways.
    First, qsort is a standard routine in ANSI/ISO C, so the rendition here
    should be given a different name, especially because the arguments to
    standard qsort are a bit different: the standard accepts a base pointer
    and a count, while this example uses a base pointer and two offsets".


    Proposed solution:

    Rename the "qsort" references, declarations and definitions as "sort" in
    the entire section 5.11.



    2. "Also, the comparison-routine argument is not treated well. The call
    shown on p 119, with an argument

    (int (*)(void*,void* ))(numeric? numcmp : strcmp)

    is not only complicated, but only barely passes muster. Both numcmp and
    strcmp take char * arguments, but this expression casts pointers to
    these functions to a function pointer that takes void * arguments. The
    standard does say that void * and char * have the same representation,
    so the example will almost certainly work in practice, and is at least
    defensible under the standard. There are too many lessons in these pages".


    Proposed solution:

    At the bottom of the page 119 (section 5.11), a note should be added:

    "Note: In main(), the call with an argument (int
    (*)(void*,void* ))(numeric? numcmp : strcmp) is not only complicated, but
    only barely passes muster. Both numcmp and strcmp take char * arguments,
    but this expression casts pointers to these functions to a function
    pointer that takes void * arguments. The standard does say that void *
    and char * have the same representation, so the example will almost
    certainly work in practice, and is at least defensible under the standard".



    3. "195(§A4.1) The first few sentences might be reworded a bit to
    emphasize that there is a distinction between storage duration and
    scope, though both are influenced by explicit and implicit storage-class
    specifiers".


    Proposed solution:

    Right after the sentence of A4.1, "Several keywords, together with the
    context of an object's declaration, specify its storage class", the
    following sentence should be added:

    "There is a distinction between storage duration and scope, though both
    are influenced by explicit and implicit storage-class specifiers".



    4. "245(§B1.3, and also at p. 157 §7.4): The scanf functions do not
    ignore white space in formats; if white space occurs at a place in the
    format, any white space in the corresponding input is skipped".


    Proposed solutions:

    On page 157 (7.4) and on page 245 (B1.3), the first sentence with a *
    (dot), should be replaced with the sentence:

    "* If white space occurs at a place in the format, any white space in
    the corresponding input is skipped".



    5. "210(§A8.1) : It is said that a register object cannot have the &
    operator applied `explicitly or implicitly,' which is true, but needs an
    amplifying clause to show that the implicit & comes from mention of an
    array name, so declaring an array as a register is fruitless".


    Proposed solution:

    On page 210 (A8.1), after the sentence "However, if an object is
    declared register, the unary & operator may not be applied to it,
    explicitly or implicitly", the following sentence should be added:

    "The implicit & comes from mention of an array name, so declaring an
    array as a register is fruitless".



    6. "There is no mention of the offsetof macro in B".

    "Index: stddef.h is listed but not summarized in the text; It needs a
    section in Appendix B".


    Proposed solutions:

    At the end of Appendix B, (page 258) the following should be added:

    "B12. Common standard type definitions: <stddef.h>

    The header <stddef.hdefine s the following types and macros:

    The types are:

    ptrdiff_t
    A signed integral type of the result of subtracting two pointers.

    wchar_t
    An integral type whose range of values can represent distinct
    wide-character codes for all members of the largest extended character
    set specified among the supported locales; the null character has the
    code value 0 and each member of the basic character set has a code value
    equal to its value when used as the lone character in an integer
    character constant.

    size_t
    An unsigned integral type of the result of the sizeof operator.


    The macros are:

    NULL
    NULL expands to an implementation-defined null pointer constant.

    offsetof(type, member-designator)
    offsetof expands to an integral constant expression of type size_t,
    the value of which is the offset in bytes to the structure member
    (member-designator), from the beginning of its structure (type)".


    Also a reference to offsetof should be added in the INDEX section (page
    268).

  • Jack Klein

    #2
    Re: Ambiguous errata solutions for K&amp;R2

    On Mon, 14 Apr 2008 16:48:49 +0300, Ioannis Vranos
    <ivranos@nospam .no.spamfreemai l.grwrote in comp.lang.c:
    In K&R2 errata page
    <http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
    there are some ambiguous errata, for which I propose solutions. Any
    comments are welcome.
    [big snip]

    My comment is that you should address your suggestions to either the
    authors of the book, or the maintainers of the errata page, should
    they be different.

    They are the ones who can decide whether your suggestions are
    appropriate.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c++-faq-lite/
    alt.comp.lang.l earn.c-c++

    Comment

    • Peter Nilsson

      #3
      Re: Ambiguous errata solutions for K&amp;R2

      Ioannis Vranos wrote:
      In K&R2 errata page
      <http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
      there are some ambiguous errata, for which I propose solutions. Any
      comments are welcome.
      The fact that your 'solutions' are in keeping with the errata suggests
      that the mentioned errata are not ambiguous.

      In many cases, the errata are simply statements that the text is
      incorrect or flawed. Few of the errata state what the rewrite should
      be, which is what your 'solutions' seem to do (without explaining
      the error in most cases.)

      Since there is no plan release K&R3 AFAIK, it seems a little pointless
      to suggest rewrites of the actual text.

      --
      Peter

      Comment

      • Ioannis Vranos

        #4
        Re: Ambiguous errata solutions for K&amp;R2

        Peter Nilsson wrote:
        Ioannis Vranos wrote:
        >In K&R2 errata page
        ><http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
        >there are some ambiguous errata, for which I propose solutions. Any
        >comments are welcome.
        >
        The fact that your 'solutions' are in keeping with the errata suggests
        that the mentioned errata are not ambiguous.

        They are ambiguous in the sense that they do not prompt the book owner
        to perform a specific solution, like the other ones.

        >
        In many cases, the errata are simply statements that the text is
        incorrect or flawed. Few of the errata state what the rewrite should
        be, which is what your 'solutions' seem to do (without explaining
        the error in most cases.)
        >
        Since there is no plan release K&R3 AFAIK, it seems a little pointless
        to suggest rewrites of the actual text.

        Well, if something is wrong or missing, why not fix it, as the rest of
        the errata of this book?

        Comment

        • Peter Nilsson

          #5
          Re: Ambiguous errata solutions for K&amp;R2

          Ioannis Vranos wrote:
          Peter Nilsson wrote:
          Ioannis Vranos wrote:
          In K&R2 errata page
          <http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
          there are some ambiguous errata, for which I propose solutions. Any
          comments are welcome.
          ...In many cases, the errata are simply statements that the text is
          incorrect or flawed. Few of the errata state what the rewrite should
          be, which is what your 'solutions' seem to do (without explaining
          the error in most cases.)

          Since there is no plan release K&R3 AFAIK, it seems a little pointless
          to suggest rewrites of the actual text.
          >
          Well, if something is wrong or missing, why not fix it,
          Presumably because the author's lives have moved on since this book
          was last published 20 years ago. I see no compelling reason to drag
          them back to the writing desk if they don't wish to do so.
          as the rest of the errata of this book?
          Ask DMR to update his errata. But replacement pages for the
          original text is not my idea of an errata.

          --
          Peter

          Comment

          • Ioannis Vranos

            #6
            Re: Ambiguous errata solutions for K&amp;R2

            Peter Nilsson wrote:
            Ioannis Vranos wrote:
            >Peter Nilsson wrote:
            >>Ioannis Vranos wrote:
            >>>In K&R2 errata page
            >>><http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
            >>>there are some ambiguous errata, for which I propose solutions. Any
            >>>comments are welcome.
            >>...In many cases, the errata are simply statements that the text is
            >>incorrect or flawed. Few of the errata state what the rewrite should
            >>be, which is what your 'solutions' seem to do (without explaining
            >>the error in most cases.)
            >>>
            >>Since there is no plan release K&R3 AFAIK, it seems a little pointless
            >>to suggest rewrites of the actual text.
            >Well, if something is wrong or missing, why not fix it,
            >
            Presumably because the author's lives have moved on since this book
            was last published 20 years ago. I see no compelling reason to drag
            them back to the writing desk if they don't wish to do so.
            I didn't drag them back without their wish.
            Ask DMR to update his errata. But replacement pages for the
            original text is not my idea of an errata.

            Well, the rest of errata were of the style:

            On page xyz, section abc, replace this with this. For the "ambiguous
            errata" I am talking about, there is not a suggested action for fixing
            the errors/ommissions. I tried to do this based strictly on their errata
            comments.


            And I wrote section B12 myself, based on C89 draft and an on-line page.
            Have you checked it?

            Comment

            • user923005

              #7
              Re: Ambiguous errata solutions for K&amp;R2

              On Apr 15, 4:13 pm, Peter Nilsson <ai...@acay.com .auwrote:
              Ioannis Vranos wrote:
              Peter Nilsson wrote:
              Ioannis Vranos wrote:
              In K&R2 errata page
              <http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>
              there are some ambiguous errata, for which I propose solutions. Any
              comments are welcome.
              >
              ...In many cases, the errata are simply statements that the text is
              incorrect or flawed. Few of the errata state what the rewrite should
              be, which is what your 'solutions' seem to do (without explaining
              the error in most cases.)
              >
              Since there is no plan release K&R3 AFAIK, it seems a little pointless
              to suggest rewrites of the actual text.
              >
              Well, if something is wrong or missing, why not fix it,
              >
              Presumably because the author's lives have moved on since this book
              was last published 20 years ago. I see no compelling reason to drag
              them back to the writing desk if they don't wish to do so.
              It's still a top seller. I guess that they would be intersted in
              suggestions for improvements
              as the rest of the errata of this book?
              >
              Ask DMR to update his errata. But replacement pages for the
              original text is not my idea of an errata.
              >
              --
              Peter- Hide quoted text -
              >
              - Show quoted text -

              Comment

              • Ioannis Vranos

                #8
                Re: Ambiguous errata solutions for K&amp;R2

                I sent via email the following to DMR and BWK:


                Dear Mr. Brian Kernighan and Mr. Dennis Ritchie,

                At the errata page of "The C Programming Language" 2nd Edition
                (<http://www-db-out.research.be ll-labs.com/cm/cs/cbook/2ediffs.html>),
                most of the errata are of the style "On page xyz, section abc, replace
                this with this" or "On page xyz, section abc, add this to this".


                However there are some errata that I call "ambiguous" , about which there
                is not a suggested specific action for fixing the errors/omissions.

                So I am sending to you some proposed solutions for these, that I made,
                based strictly on their errata comments.


                These proposed solutions are to be added to the errata page exactly as
                they appear after the phrase "Proposed solution:", replacing their
                "ambiguous" corresponding text.




                1. "119-121(§5.11): The qsort discussion needs recasting in several
                ways. First, qsort is a standard routine in ANSI/ISO C, so the rendition
                here should be given a different name, especially because the arguments
                to standard qsort are a bit different: the standard accepts a base
                pointer and a count, while this example uses a base pointer and two
                offsets".


                Proposed solution:

                Rename the "qsort" references, declarations, definitions and calls, as
                "sort" in the entire section 5.11.



                2. "Also, the comparison-routine argument is not treated well. The call
                shown on p 119, with an argument

                (int (*)(void*,void* ))(numeric? numcmp : strcmp)

                is not only complicated, but only barely passes muster. Both numcmp and
                strcmp take char * arguments, but this expression casts pointers to
                these functions to a function pointer that takes void * arguments. The
                standard does say that void * and char * have the same representation,
                so the example will almost certainly work in practice, and is at least
                defensible under the standard. There are too many lessons in these pages".


                Proposed solution:

                At the bottom of the page 119 (section 5.11), a note should be added:

                "Note: In main(), the call with an argument (int
                (*)(void*,void* ))(numeric? numcmp : strcmp) is not only complicated, but
                only barely passes muster. Both numcmp and strcmp take char * arguments,
                but this expression casts pointers to these functions to a function
                pointer that takes void * arguments. The standard does say that void *
                and char * have the same representation, so the example will almost
                certainly work in practice, and is at least defensible under the standard".



                3. "195(§A4.1) The first few sentences might be reworded a bit to
                emphasize that there is a distinction between storage duration and
                scope, though both are influenced by explicit and implicit storage-class
                specifiers".


                Proposed solution:

                Right after the sentence of A4.1, "Several keywords, together with the
                context of an object's declaration, specify its storage class", the
                following sentence should be added:

                "There is a distinction between storage duration and scope, though both
                are influenced by explicit and implicit storage-class specifiers".



                4. "245(§B1.3, and also at p. 157 §7.4): The scanf functions do not
                ignore white space in formats; if white space occurs at a place in the
                format, any white space in the corresponding input is skipped".


                Proposed solution:

                On page 157 (7.4) and on page 245 (B1.3), the first sentence with a *
                (dot), should be replaced with the sentence:

                "* If white space occurs at a place in the format, any white space in
                the corresponding input is skipped".



                5. "210(§A8.1) : It is said that a register object cannot have the &
                operator applied `explicitly or implicitly,' which is true, but needs an
                amplifying clause to show that the implicit & comes from mention of an
                array name, so declaring an array as a register is fruitless".


                Proposed solution:

                On page 210 (A8.1), after the sentence "However, if an object is
                declared register, the unary & operator may not be applied to it,
                explicitly or implicitly", the following sentence should be added:

                "The implicit & comes from mention of an array name, so declaring an
                array as a register is fruitless".



                6. "There is no mention of the offsetof macro in B".

                "Index: stddef.h is listed but not summarized in the text; It needs a
                section in Appendix B".


                Proposed solution:

                At the end of Appendix B (page 258), the following should be added:

                "B12. Common standard type definitions: <stddef.h>

                The header <stddef.hdefine s the following types and macros:

                The types are:

                ptrdiff_t
                A signed integral type of the result of subtracting two pointers.

                wchar_t
                An integral type whose range of values can represent distinct
                wide-character codes for all members of the largest extended character
                set specified among the supported locales; the null character has the
                code value 0 and each member of the basic character set has a code value
                equal to its value when used as the lone character in an integer
                character constant.

                size_t
                An unsigned integral type of the result of the sizeof operator.


                The macros are:

                NULL
                NULL expands to an implementation-defined null pointer constant.

                offsetof(type, member-designator)
                offsetof expands to an integral constant expression of type size_t,
                the value of which is the offset in bytes to the structure member
                (member-designator), from the beginning of its structure (type)".


                Also a reference to offsetof should be added in the INDEX section (page
                268), and the page number 258 should be added to the reference of
                <stddef.hheader , in the INDEX section (page 270).

                Comment

                Working...