A question about fputs()

Discussion in 'C Programming' started by Chad, Jun 22, 2008.

  1. Chad

    Chad Guest

    Why doesn't fputs() write the null byte when the null-terminted string
    is written to a stream? I don't see the reasoning behind this.

    Chad
     
    Chad, Jun 22, 2008
    #1
    1. Advertising

  2. Chad

    Chad Guest

    On Jun 22, 8:58 am, Richard Heathfield <> wrote:
    > Chad said:
    >
    > > Why doesn't fputs() write the null byte when the null-terminted string
    > > is written to a stream? I don't see the reasoning behind this.

    >
    > Perhaps you could explain why you think a text-oriented function like fputs
    > should concern itself with a non-text-oriented value such as a null byte?
    > I don't see the reasoning behind /that/.
    >


    Let's say I have a string like the following

    "This is a string\n"

    Wouldn't this create undefined behavior if puts removes '\n'?
     
    Chad, Jun 22, 2008
    #2
    1. Advertising

  3. Chad

    Guest

    On Jun 22, 7:03 pm, Chad <> wrote:
    > On Jun 22, 8:58 am, Richard Heathfield <> wrote:
    >
    > > Chad said:

    >
    > > > Why doesn't fputs() write the null byte when the null-terminted string
    > > > is written to a stream? I don't see the reasoning behind this.

    >
    > > Perhaps you could explain why you think a text-oriented function like fputs
    > > should concern itself with a non-text-oriented value such as a null byte?
    > > I don't see the reasoning behind /that/.

    >
    > Let's say I have a string like the following
    >
    > "This is a string\n"
    >
    > Wouldn't this create undefined behavior if puts removes '\n'?


    puts or fputs()?
    Regardless, each function *will* write the string provided.
    The difference is that puts() does not take the file stream to write
    to as an argument, and that puts() also writes a newline, after the
    string.
    If you really want to know what happened, preserve the return value.
    Undefined behavior occurs because of the user-programmer, not the
    implementation. (in a perfect world with a perfect implementation).
     
    , Jun 22, 2008
    #3
  4. Chad

    Chad Guest

    On Jun 22, 9:11 am, Richard Heathfield <> wrote:
    > Chad said:
    >
    >
    >
    > > On Jun 22, 8:58 am, Richard Heathfield <> wrote:
    > >> Chad said:

    >
    > >> > Why doesn't fputs() write thenullbytewhen thenull-terminted string
    > >> > is written to a stream? I don't see the reasoning behind this.

    >
    > >> Perhaps you could explain why you think a text-oriented function like
    > >> fputs should concern itself with a non-text-oriented value such as a
    > >>nullbyte? I don't see the reasoning behind /that/.

    >
    > > Let's say I have a string like the following

    >
    > > "This is a string\n"

    >
    > > Wouldn't this create undefined behavior if puts removes '\n'?

    >
    > I can go further than that, and say that it would be printed out backwards
    > if puts printed stuff out backwards. But puts doesn't do that - and it
    > doesn't remove newlines either. Text is a line-oriented format, and a line
    > is defined by newlines (insofar as a newline appears at the end of every
    > line). The puts function, which is a text-oriented function, would be a
    > very strange bird indeed if it removed newlines. I don't see the point you
    > are trying to make. If you are trying to draw a comparison betweennull
    > bytes and newlines, it doesn't work - newlines are a fundamental part of
    > text streams, whereasnullbytes are not.
    >
    > --


    I'm hesitant to quote the following because it doesn't really fall
    under the realm of C. Here is the quote from page 143 in the book
    'Advanced Programming in the Unix Environment", Second Edition, by
    Stevens and Rago

    "The function fputs writes the null-terminated string to the specified
    stream. The null byte at the end is not written. Note that this need
    not be line-at-a-time-output, since the string need not contain a
    newline as the last non-null character. Usually this is the case - the
    last non-null character is a newline - but it's not required."
     
    Chad, Jun 22, 2008
    #4
  5. Chad

    Chad Guest

    On Jun 22, 9:10 am, wrote:
    > On Jun 22, 7:03 pm, Chad <> wrote:
    >
    >
    >
    > > On Jun 22, 8:58 am, Richard Heathfield <> wrote:

    >
    > > > Chad said:

    >
    > > > > Why doesn't fputs() write thenullbytewhen thenull-terminted string
    > > > > is written to a stream? I don't see the reasoning behind this.

    >
    > > > Perhaps you could explain why you think a text-oriented function like fputs
    > > > should concern itself with a non-text-oriented value such as anullbyte?
    > > > I don't see the reasoning behind /that/.

    >
    > > Let's say I have a string like the following

    >
    > > "This is a string\n"

    >
    > > Wouldn't this create undefined behavior if puts removes '\n'?

    >
    > puts or fputs()?
    > Regardless, each function *will* write the string provided.
    > The difference is that puts() does not take the file stream to write
    > to as an argument, and that puts() also writes a newline, after the
    > string.
    > If you really want to know what happened, preserve the return value.
    > Undefined behavior occurs because of the user-programmer, not the
    > implementation. (in a perfect world with a perfect implementation).



    I meant fputs(). Quote the linux man page on fputs()

    " fputs() writes the string s to stream, without its trailing ’\0’."

    I don't see why it omits the trailing '\0'.
     
    Chad, Jun 22, 2008
    #5
  6. Chad

    Chad Guest

    On Jun 22, 9:23 am, Joe Wright <> wrote:
    > Chad wrote:
    > > Why doesn't fputs() write thenullbyte when thenull-terminted string
    > > is written to a stream? I don't see the reasoning behind this.

    >
    > > Chad

    >
    > The asciicharacterNUL does not normally appear in a text stream. It is
    > used in memory as a 'string' terminator. Text streams are typically
    > organized as some number of characters terminated with '\n', a 'line',
    > and any number of lines.
    >
    > The fgets() function will read a line from the text stream, including
    > the '\n' into a char array and terminate it with NUL making the whole
    > thing a 'string' in memory. Then fputs() can write the array to a text
    > stream up to and including the '\n'.
    >
    > The NUL is a controlcharacterused to define a string in memory. It is
    > not part of the data read with fgets() or written with fputs().
    >


    Okay. I think I see it. I guess I was blurring the distinction between
    a 'text string' vs a 'string'.
     
    Chad, Jun 22, 2008
    #6
  7. On Sun, 22 Jun 2008 09:21:19 -0700 (PDT), Chad <>
    wrote:

    >On Jun 22, 9:10 am, wrote:
    >> On Jun 22, 7:03 pm, Chad <> wrote:
    >>


    >> > Let's say I have a string like the following

    >>
    >> > "This is a string\n"

    >>
    >> > Wouldn't this create undefined behavior if puts removes '\n'?

    >>
    >> puts or fputs()?
    >> Regardless, each function *will* write the string provided.
    >> The difference is that puts() does not take the file stream to write
    >> to as an argument, and that puts() also writes a newline, after the
    >> string.
    >> If you really want to know what happened, preserve the return value.
    >> Undefined behavior occurs because of the user-programmer, not the
    >> implementation. (in a perfect world with a perfect implementation).

    >
    >
    >I meant fputs(). Quote the linux man page on fputs()
    >
    >" fputs() writes the string s to stream, without its trailing ’\0’."
    >
    >I don't see why it omits the trailing '\0'.


    fputs() cannot tell the difference between a trailing '\0', and the
    marker for the end of string (which is '\0'). Standard strings in C
    are always null-terminated, and the library functions will treat those
    strings in that fashion.

    It's similar to why strcat(str, "\0") doesn't do anything - it finds
    the '\0' within the string and appends the empty string to that
    location.

    If you need to write null characters, you could try fputc or a
    function dedicated to writing binary data.
     
    Raymond Martineau, Jun 22, 2008
    #7
  8. Chad

    Bartc Guest

    "Chad" <> wrote in message
    news:...
    > On Jun 22, 9:23 am, Joe Wright <> wrote:
    >> Chad wrote:
    >> > Why doesn't fputs() write thenullbyte when thenull-terminted string
    >> > is written to a stream? I don't see the reasoning behind this.

    >>
    >> > Chad

    >>
    >> The asciicharacterNUL does not normally appear in a text stream. It is
    >> used in memory as a 'string' terminator. Text streams are typically
    >> organized as some number of characters terminated with '\n', a 'line',
    >> and any number of lines.
    >>
    >> The fgets() function will read a line from the text stream, including
    >> the '\n' into a char array and terminate it with NUL making the whole
    >> thing a 'string' in memory. Then fputs() can write the array to a text
    >> stream up to and including the '\n'.
    >>
    >> The NUL is a controlcharacterused to define a string in memory. It is
    >> not part of the data read with fgets() or written with fputs().
    >>

    >
    > Okay. I think I see it. I guess I was blurring the distinction between
    > a 'text string' vs a 'string'.


    I don't think there is a distinction.

    puts() writes your string then adds a newline '\n'

    fputs() writes your string. It doesn't add a newline of it's own.

    The behaviour may be to mirror the action of gets() (which absorbs a newline
    on input, so puts() has to regenerate it). And of fgets() (which retains the
    newline, and therefore fgets() expects your string to contain a newline, if
    you need it).

    This is nothing to do with text/non text strings. (Also note gets() function
    is not recommended for use anymore, which could be why mixing fgets() and
    puts() might give these little problems.)

    --
    Bartc
     
    Bartc, Jun 22, 2008
    #8
  9. Chad

    Daniel Pitts Guest

    Chad wrote:
    > Why doesn't fputs() write the null byte when the null-terminted string
    > is written to a stream? I don't see the reasoning behind this.
    >
    > Chad

    By definition, the null marks the location "one past" the end of the
    usable string. fputs writes the usable portion of the string.
    If you want to save the null, use fputc(0, f); after you write the string.
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Jun 22, 2008
    #9
  10. Chad

    Daniel Pitts Guest

    Chad wrote:
    > On Jun 22, 9:11 am, Richard Heathfield <> wrote:
    >> Chad said:
    >>
    >>
    >>
    >>> On Jun 22, 8:58 am, Richard Heathfield <> wrote:
    >>>> Chad said:
    >>>>> Why doesn't fputs() write thenullbytewhen thenull-terminted string
    >>>>> is written to a stream? I don't see the reasoning behind this.
    >>>> Perhaps you could explain why you think a text-oriented function like
    >>>> fputs should concern itself with a non-text-oriented value such as a
    >>>> nullbyte? I don't see the reasoning behind /that/.
    >>> Let's say I have a string like the following
    >>> "This is a string\n"
    >>> Wouldn't this create undefined behavior if puts removes '\n'?

    > I'm hesitant to quote the following because it doesn't really fall
    > under the realm of C. Here is the quote from page 143 in the book
    > 'Advanced Programming in the Unix Environment", Second Edition, by
    > Stevens and Rago
    >
    > "The function fputs writes the null-terminated string to the specified
    > stream. The null byte at the end is not written. Note that this need
    > not be line-at-a-time-output, since the string need not contain a
    > newline as the last non-null character. Usually this is the case - the
    > last non-null character is a newline - but it's not required."


    Think about this: puts("My line\nand another line\n") will put two lines.

    fputs("My line\nand another line\n", file) will also put two lines. \n
    doesn't end the string, and puts will put the whole null-terminated
    string (minues the null).

    Now, puts("My line\n\0and more\n") will only put "My Line\n". Just like
    what fputs would do! Why would you expect them to behave differently?



    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Jun 22, 2008
    #10
  11. Chad <> writes:
    > On Jun 22, 9:23 am, Joe Wright <> wrote:
    >> Chad wrote:
    >> > Why doesn't fputs() write thenullbyte when thenull-terminted string
    >> > is written to a stream? I don't see the reasoning behind this.

    >>
    >> The asciicharacterNUL does not normally appear in a text stream. It is
    >> used in memory as a 'string' terminator. Text streams are typically
    >> organized as some number of characters terminated with '\n', a 'line',
    >> and any number of lines.
    >>
    >> The fgets() function will read a line from the text stream, including
    >> the '\n' into a char array and terminate it with NUL making the whole
    >> thing a 'string' in memory. Then fputs() can write the array to a text
    >> stream up to and including the '\n'.
    >>
    >> The NUL is a controlcharacterused to define a string in memory. It is
    >> not part of the data read with fgets() or written with fputs().

    >
    > Okay. I think I see it. I guess I was blurring the distinction between
    > a 'text string' vs a 'string'.


    No, the distinction you're blurring is between a "line" (in a text
    file) and a "string" (in memory).

    A line in a text file is terminated by some sort of end-of-line
    indicator, which is translated to a '\n' character when the line is
    read.

    A string is terminated by (and includes) a '\0' (null character).

    You normally *don't* want null characters in text files.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 22, 2008
    #11
  12. Chad

    Chad Guest

    On Jun 22, 11:49 am, Richard Heathfield <> wrote:
    > Chad said:
    >
    > <snip>
    >
    > > I'm hesitant to quote the following because it doesn't really fall
    > > under the realm of C. Here is the quote from page 143 in the book
    > > 'Advanced Programming in the Unix Environment", Second Edition, by
    > > Stevens and Rago

    >
    > > "The function fputs writes the null-terminated string to the specified
    > > stream. The null byte at the end is not written.

    >
    > Right. And your question was "why doesn't it write the null byte", yes? So
    > why are you focussing so much on newlines?
    >
    > > Note that this need
    > > not be line-at-a-time-output, since the string need not contain a
    > > newline as the last non-null character. Usually this is the case - the
    > > last non-null character is a newline - but it's not required."

    >
    > C defines a text file as a series of lines, and a line as zero or more
    > characters terminated by a newline. Whether the last line of a text file
    > /requires/ a newline is implementation-defined (but note that this doesn't
    > apply to C source files - they *shall* end in a newline, so there!), but
    > it's always permitted and therefore always sensible to add one.
    >
    > Now, I have a question for you. What are you really asking about - null
    > bytes, or newlines?
    >
    > --


    Okay, I don't know. Maybe this might give you some insight into what
    I'm thinking. Say I have something like

    fputs("line", file)

    We would have 'l' 'i' 'n' 'e' '\0',

    When it put into memory (say from fgets), would it have been

    'l' 'i' 'n' 'e' '\0'

    or

    'l' 'i' 'n' 'e' '\0' '\0'

    ?

    If it was the latter, then I guess fputs would have written out

    'l' 'i' 'n' 'e' '\0'

    However, if it was the former, then wouldn't fputs have written out

    'l' 'i' 'n' 'e'

    ?
     
    Chad, Jun 22, 2008
    #12
  13. Chad

    Bartc Guest

    Chad wrote:
    > On Jun 22, 11:49 am, Richard Heathfield <> wrote:


    >> Now, I have a question for you. What are you really asking about -
    >> null bytes, or newlines?


    > Okay, I don't know. Maybe this might give you some insight into what
    > I'm thinking. Say I have something like
    >
    > fputs("line", file)
    >
    > We would have 'l' 'i' 'n' 'e' '\0',


    No. It will just write 'l' 'i' 'n' 'e' to the file (4 bytes).


    > When it put into memory (say from fgets), would it have been
    >
    > 'l' 'i' 'n' 'e' '\0'


    fgets() would normally return something like:

    'l' 'i' 'n' 'e' '\n' '\0'

    if "line" was followed by a newline character in the file. The '\0' is added
    by fgets(). If your example file really did consist only of the 4 bytes of
    "line", then I'm guessing it will return:

    'l' 'i' 'n' 'e' '\0'

    Maybe you should just try it out to experiment.

    > If it was the latter, then I guess fputs would have written out
    >
    > 'l' 'i' 'n' 'e' '\0'


    No. The '\0' is only their to mark the end of the string. The only confusion
    I can see is that the docs for puts() (not fputs()) may mention converting
    this nul char to newline. It should just say it writes a new line after the
    rest of the string.

    --
    Bartc
     
    Bartc, Jun 22, 2008
    #13
  14. Chad

    santosh Guest

    Chad wrote:

    > On Jun 22, 11:49 am, Richard Heathfield <> wrote:
    >> Chad said:
    >>
    >> <snip>
    >>
    >> > I'm hesitant to quote the following because it doesn't really fall
    >> > under the realm of C. Here is the quote from page 143 in the book
    >> > 'Advanced Programming in the Unix Environment", Second Edition, by
    >> > Stevens and Rago

    >>
    >> > "The function fputs writes the null-terminated string to the
    >> > specified stream. The null byte at the end is not written.

    >>
    >> Right. And your question was "why doesn't it write the null byte",
    >> yes? So why are you focussing so much on newlines?
    >>
    >> > Note that this need
    >> > not be line-at-a-time-output, since the string need not contain a
    >> > newline as the last non-null character. Usually this is the case -
    >> > the last non-null character is a newline - but it's not required."

    >>
    >> C defines a text file as a series of lines, and a line as zero or
    >> more characters terminated by a newline. Whether the last line of a
    >> text file /requires/ a newline is implementation-defined (but note
    >> that this doesn't apply to C source files - they *shall* end in a
    >> newline, so there!), but it's always permitted and therefore always
    >> sensible to add one.
    >>
    >> Now, I have a question for you. What are you really asking about -
    >> null bytes, or newlines?
    >>
    >> --

    >
    > Okay, I don't know. Maybe this might give you some insight into what
    > I'm thinking. Say I have something like
    >
    > fputs("line", file)
    >
    > We would have 'l' 'i' 'n' 'e' '\0',


    No,fputs will not write the terminating null to the stream.

    > When it put into memory (say from fgets), would it have been
    >
    > 'l' 'i' 'n' 'e' '\0'


    Yes, provided the array passed to fgets has sufficient size,
    otherwise "line" will be truncated, but the terminating null character
    will always be written.

    > or
    >
    > 'l' 'i' 'n' 'e' '\0' '\0'
    >
    > ?


    No. This isn't correct.

    > If it was the latter, then I guess fputs would have written out
    >
    > 'l' 'i' 'n' 'e' '\0'


    No.

    > However, if it was the former, then wouldn't fputs have written out
    >
    > 'l' 'i' 'n' 'e'
    >
    > ?


    Yes.
     
    santosh, Jun 23, 2008
    #14
  15. Chad

    santosh Guest

    pete wrote:

    > Chad wrote:
    >> Why doesn't fputs() write the null byte when the null-terminted
    >> string is written to a stream? I don't see the reasoning behind this.

    >
    > #include <ctype.h>
    >
    > isprint('\0') may equal zero or maybe always equals zero.
    >
    > Text files with nonprinting characters aren't guaranteed
    > to read back the same way that they are written.
    > They're not nice text files.


    But puts/fputs need not be used with text files alone.
     
    santosh, Jun 23, 2008
    #15
  16. Chad

    rahul Guest

    On Jun 22, 8:46 pm, Chad <> wrote:
    > Why doesn't fputs() write the null byte when the null-terminted string
    > is written to a stream? I don't see the reasoning behind this.
    >
    > Chad


    Well, it is defined that way because the null byte is just for C to
    know about the end of the character array. It is used just as a marker
    and not considered as an actual character when writing to console,
    disk or any other stream.
     
    rahul, Jun 23, 2008
    #16
  17. Chad <> writes:
    [...]
    > Okay, I don't know. Maybe this might give you some insight into what
    > I'm thinking. Say I have something like
    >
    > fputs("line", file)
    >
    > We would have 'l' 'i' 'n' 'e' '\0',


    The phrase "We would have" is vague.

    The string literal "line" in your source specifies that an array
    containing the sequence { 'l', 'i', 'n', 'e', '\0' } exists in memory
    as your program executes. A pointer to the first element of that
    array is passed to the fputs function.

    The characters written to the file by the fputs function are 'l', 'i',
    'n', and 'e'. fputs does not write either a '\0' or a '\n' to the
    file.

    > When it put into memory (say from fgets), would it have been
    >
    > 'l' 'i' 'n' 'e' '\0'
    >
    > or
    >
    > 'l' 'i' 'n' 'e' '\0' '\0'
    >
    > ?


    You need to be much clearer about what you're doing.

    The fgets() function reads a *line* of text from an input file, up to
    and including the '\n' character that marks the end of the line. (It
    may or may not be represented that way in the external file.)

    If a text file starts with 'l', 'i', 'n', 'e', '\n', and you read from
    that file using fgets() with a sufficiently long array and a
    sufficiently large second argument, then fgets() will store { 'l',
    'i', 'n', 'e', '\n', '\0' } in the array.

    In some circumstances, fgets won't read a full line. In that case, it
    might store just { 'l', 'i', 'n', 'e', '\0' } in the array.

    It will *always* store the trailing '\0', ensuring that the array will
    contain a valid string.

    [snip]

    It (almost) *never* makes sense to write a null character '\0' to a
    text stream. '\0' is used to mark the end of a string in memory in a
    running C program; it has no particular meaning in a text file. (You
    can write '\0', or anything else, to a binary file.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 23, 2008
    #17
  18. santosh <> writes:
    > pete wrote:
    > > Chad wrote:
    > >> Why doesn't fputs() write the null byte when the null-terminted
    > >> string is written to a stream? I don't see the reasoning behind this.

    > >
    > > #include <ctype.h>
    > >
    > > isprint('\0') may equal zero or maybe always equals zero.
    > >
    > > Text files with nonprinting characters aren't guaranteed
    > > to read back the same way that they are written.
    > > They're not nice text files.

    >
    > But puts/fputs need not be used with text files alone.


    That's quite true. Both puts and fputs work as if by successive calls
    to fputc.

    But puts and fputs are *intended* to work with strings, which why both
    of them will print only characters up to *but not including* the
    terminating '\0'.

    You can write '\0' characters to a binary stream (or to a text stream,
    for that matter), but you can't use puts or fputs to do it.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 23, 2008
    #18
    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. xoinki
    Replies:
    1
    Views:
    396
  2. dave
    Replies:
    4
    Views:
    689
  3. Petr Gotthard

    fputs in tp_print crashes under Win32

    Petr Gotthard, Nov 12, 2008, in forum: Python
    Replies:
    1
    Views:
    330
    Gabriel Genellina
    Nov 15, 2008
  4. _JusSx_

    fputs and fprintf

    _JusSx_, Feb 28, 2010, in forum: C Programming
    Replies:
    10
    Views:
    5,081
    santosh
    Feb 28, 2010
  5. hassan

    fputs

    hassan, Jun 5, 2012, in forum: Python
    Replies:
    1
    Views:
    288
    Ulrich Eckhardt
    Jun 5, 2012
Loading...

Share This Page