Re: K&R Ex 1-22

Discussion in 'C Programming' started by David Thompson, Sep 1, 2008.

  1. On Tue, 19 Aug 2008 14:30:25 +0000, Richard Heathfield
    <> wrote:

    > On line 50, '\n' is actually of type int, would you believe? But we know
    > its value must fit in a char (for several reasons, one of which is that it
    > is a mandatory member of the source character set, so it must have a value
    > in the range 1 to CHAR_MAX), so it's okay to pass it to ... char ....


    Nit: of the basic execution charset. Which is what matters here,
    6.2.5p3. 5.1.1.2 does talk about newlines, but 5.2.1p3 more
    specifically (and thus I consider controllingly) says an
    (impl-dependent) indicator 'treat[ed] as' a newline.

    (This is really angels-on-a-pinhead: something that acts like a
    newline, as a source char which cannot be accessed by the program, and
    if it is converted to an execution char only as an extension becomes a
    newline, but isn't formally a newline.)

    - formerly david.thompson1 || achar(64) || worldnet.att.net
    David Thompson, Sep 1, 2008
    #1
    1. Advertising

  2. David Thompson

    Ron Ford Guest

    On Mon, 01 Sep 2008 06:53:21 GMT, David Thompson posted:

    > On Tue, 19 Aug 2008 14:30:25 +0000, Richard Heathfield
    > <> wrote:
    >
    >> On line 50, '\n' is actually of type int, would you believe? But we know
    >> its value must fit in a char (for several reasons, one of which is that it
    >> is a mandatory member of the source character set, so it must have a value
    >> in the range 1 to CHAR_MAX), so it's okay to pass it to ... char ....

    >
    > Nit: of the basic execution charset. Which is what matters here,
    > 6.2.5p3. 5.1.1.2 does talk about newlines, but 5.2.1p3 more
    > specifically (and thus I consider controllingly) says an
    > (impl-dependent) indicator 'treat[ed] as' a newline.
    >
    > (This is really angels-on-a-pinhead: something that acts like a
    > newline, as a source char which cannot be accessed by the program, and
    > if it is converted to an execution char only as an extension becomes a
    > newline, but isn't formally a newline.)


    I'd like to see an illustrative snippet.

    --
    We must respect the other fellow's religion, but only in the sense and to
    the extent that we respect his theory that his wife is beautiful and his
    children smart. 5
    H. L. Mencken
    Ron Ford, Sep 3, 2008
    #2
    1. Advertising

  3. David Thompson

    James Kuyper Guest

    Ron Ford wrote:
    > On Mon, 01 Sep 2008 06:53:21 GMT, David Thompson posted:
    >
    >> On Tue, 19 Aug 2008 14:30:25 +0000, Richard Heathfield
    >> <> wrote:
    >>
    >>> On line 50, '\n' is actually of type int, would you believe? But we know
    >>> its value must fit in a char (for several reasons, one of which is that it
    >>> is a mandatory member of the source character set, so it must have a value
    >>> in the range 1 to CHAR_MAX), so it's okay to pass it to ... char ....

    >> Nit: of the basic execution charset. Which is what matters here,
    >> 6.2.5p3. 5.1.1.2 does talk about newlines, but 5.2.1p3 more
    >> specifically (and thus I consider controllingly) says an
    >> (impl-dependent) indicator 'treat[ed] as' a newline.


    In n1256.pdf, the wording is:

    "In source files, there shall be some way of indicating the end of each
    line of text; this International Standard treats such an end-of-line
    indicator as if it were a single new-line character."

    >> (This is really angels-on-a-pinhead: something that acts like a
    >> newline, as a source char which cannot be accessed by the program, and
    >> if it is converted to an execution char only as an extension becomes a
    >> newline, but isn't formally a newline.)

    >
    > I'd like to see an illustrative snippet.


    The basic idea is that the C standard allows the same type of freedom of
    representation for C source code files that it allows for files written
    or read by C programs in text mode. What is treated as a single '\n'
    character for purposes of parsing the C code might be represented by any
    of the following in the source code file (among many other possibilities):

    * '\n' followed by '\r'
    * '\r' followed by '\n'
    * '\r'
    * text is stored in fixed-length blocks. When a line ends inside a
    block, instead of writing a '\n' character into the block, the block is
    padded to the end with '\0' characters.
    * Same as previous, but the padding is with blanks.
    * Same as previous, but each block contains a count of the number of
    characters actually stored in the block - the contents of the rest of
    the block are irrelevant. If the number of characters stored is less
    less than the capacity of the block, that indicates the end of a line.

    Most of the possibilities listed above are in actual current use.
    James Kuyper, Sep 3, 2008
    #3
    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.

Share This Page