puts vs fputs

Discussion in 'C Programming' started by boltar2003@boltar.world, Jul 20, 2012.

  1. Guest

    Is there any logic behind puts() adding a newline but fputs() not doing it?
    Or was it just a design **** up in the early days of C?

    B2003
     
    , Jul 20, 2012
    #1
    1. Advertising

  2. jacob navia Guest

    Le 20/07/12 11:15, a écrit :
    > Is there any logic behind puts() adding a newline but fputs() not doing it?
    > Or was it just a design **** up in the early days of C?
    >
    > B2003
    >


    The standard output stream is line buffered by default, i.e. it will
    never output something unless it sees a carriage return. That is why
    puts() that writes its output to standard output needs a new line.

    fputs() doesn't need a new line since the stream is in most cases not
    the standard output and it is buffered, not line buffered.

    Before treating things like that as "design fuckups" try to understand
    why they are so designed.

    jacob
     
    jacob navia, Jul 20, 2012
    #2
    1. Advertising

  3. Guest

    On Fri, 20 Jul 2012 12:38:37 +0200
    jacob navia <> wrote:
    >The standard output stream is line buffered by default, i.e. it will
    >never output something unless it sees a carriage return. That is why
    >puts() that writes its output to standard output needs a new line.
    >
    >fputs() doesn't need a new line since the stream is in most cases not
    >the standard output and it is buffered, not line buffered.


    Thats not a good enough reason for the inconsistent behaviour IMO.

    >Before treating things like that as "design fuckups" try to understand
    >why they are so designed.


    I didn't, I asked whether it was one. Perhaps your understanding of english
    isn't as good as you think.

    B2003
     
    , Jul 20, 2012
    #3
  4. jacob navia Guest

    Le 20/07/12 12:41, a écrit :
    > On Fri, 20 Jul 2012 12:38:37 +0200
    > jacob navia <> wrote:
    >> The standard output stream is line buffered by default, i.e. it will
    >> never output something unless it sees a carriage return. That is why
    >> puts() that writes its output to standard output needs a new line.
    >>
    >> fputs() doesn't need a new line since the stream is in most cases not
    >> the standard output and it is buffered, not line buffered.

    >
    > Thats not a good enough reason for the inconsistent behaviour IMO.
    >


    If you do not put the new line, when you write:

    puts("Please enter a number");

    you will not see anything...


    Thats a good enough reason for the inconsistent behaviour IMO.
     
    jacob navia, Jul 20, 2012
    #4
  5. Guest

    On Fri, 20 Jul 2012 12:54:27 +0200
    jacob navia <> wrote:
    >Le 20/07/12 12:41, a écrit :
    >> On Fri, 20 Jul 2012 12:38:37 +0200
    >> jacob navia <> wrote:
    >>> The standard output stream is line buffered by default, i.e. it will
    >>> never output something unless it sees a carriage return. That is why
    >>> puts() that writes its output to standard output needs a new line.
    >>>
    >>> fputs() doesn't need a new line since the stream is in most cases not
    >>> the standard output and it is buffered, not line buffered.

    >>
    >> Thats not a good enough reason for the inconsistent behaviour IMO.
    >>

    >
    >If you do not put the new line, when you write:
    >
    >puts("Please enter a number");
    >
    >you will not see anything...
    >
    >
    >Thats a good enough reason for the inconsistent behaviour IMO.


    Really, so why didn't they use the same logic with the printf functions then?
    Why didn't they specify printf() to do an automatic newline but fprintf() not?

    B2003
     
    , Jul 20, 2012
    #5
  6. jacob navia Guest

    Le 20/07/12 13:13, a écrit :
    > why didn't they use the same logic with the printf functions then?
    > Why didn't they specify printf() to do an automatic newline but fprintf() not?


    Because printf is a run time interpreter of its format string.

    When you use printf you do want EXACT control of the output,
    not just put a string (puts) in the screen, adding a new line
    would break the precise formatting instructions.

    Puts(string) is equivalent to printf("%s\n", string);

    jacob
     
    jacob navia, Jul 20, 2012
    #6
  7. Guest

    On Fri, 20 Jul 2012 14:23:04 +0200
    jacob navia <> wrote:
    >Le 20/07/12 13:13, a écrit :
    >> why didn't they use the same logic with the printf functions then?
    >> Why didn't they specify printf() to do an automatic newline but fprintf()

    >not?
    >
    >Because printf is a run time interpreter of its format string.
    >
    >When you use printf you do want EXACT control of the output,
    >not just put a string (puts) in the screen, adding a new line
    >would break the precise formatting instructions.


    You're just making this up as you go along arn't you? Your argument lacks
    any logic whatsoever. A family of functions should have consistent
    functionality. End of.

    B2003
     
    , Jul 20, 2012
    #7
  8. jacob navia Guest

    Le 20/07/12 14:54, a écrit :
    > On Fri, 20 Jul 2012 14:23:04 +0200
    > jacob navia <> wrote:
    >> Le 20/07/12 13:13, a écrit :
    >>> why didn't they use the same logic with the printf functions then?
    >>> Why didn't they specify printf() to do an automatic newline but fprintf()

    >> not?
    >>
    >> Because printf is a run time interpreter of its format string.
    >>
    >> When you use printf you do want EXACT control of the output,
    >> not just put a string (puts) in the screen, adding a new line
    >> would break the precise formatting instructions.

    >
    > You're just making this up as you go along arn't you? Your argument lacks
    > any logic whatsoever. A family of functions should have consistent
    > functionality. End of.
    >
    > B2003
    >
    >


    OK. Look, you are unhappy?

    Please complain to the committee. I can only give you the reasons why
    this is so.

    Should be changed?

    Maybe, personally I do not mind about the extra newline of puts() since
    I seldom use it.

    End of story.
     
    jacob navia, Jul 20, 2012
    #8
  9. jacob navia <> writes:

    > Please complain to the committee. I can only give you the reasons
    > why this is so.


    Not really. It looks more like your own guesses.

    Take a look at
    <http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>


    7.19.7.10 The puts function
    puts(s) is not exactly equivalent to fputs(stdout,s); and puts also
    writes a newline after the argument string. This incompatibility
    reflects existing practice.

    --
    /Wegge

    Leder efter redundant peering af dk.*,linux.debian.*
     
    Anders Wegge Keller, Jul 20, 2012
    #9
  10. In article <>,
    Anders Wegge Keller <> wrote:

    > jacob navia <> writes:
    >
    > > Please complain to the committee. I can only give you the reasons
    > > why this is so.

    >
    > Not really. It looks more like your own guesses.
    >
    > Take a look at
    > <http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>
    >
    >
    > 7.19.7.10 The puts function
    > puts(s) is not exactly equivalent to fputs(stdout,s); and puts also
    > writes a newline after the argument string. This incompatibility
    > reflects existing practice.


    How is that different than what Jacob (with more patience than I have)
    explained? All you quoted was that it 'reflects existing practice'.
    Jacob explained why that practice existed.
     
    Mark Storkamp, Jul 20, 2012
    #10
  11. Mark Storkamp <> writes:

    > How is that different than what Jacob (with more patience than I
    > have) explained? All you quoted was that it 'reflects existing
    > practice'. Jacob explained why that practice existed.


    The OP asked why the standadrs committee defined the semantics thus.

    --
    /Wegge

    Leder efter redundant peering af dk.*,linux.debian.*
     
    Anders Wegge Keller, Jul 20, 2012
    #11
  12. jacob navia Guest

    Le 20/07/12 18:14, Anders Wegge Keller a écrit :
    > Mark Storkamp <> writes:
    >
    >> How is that different than what Jacob (with more patience than I
    >> have) explained? All you quoted was that it 'reflects existing
    >> practice'. Jacob explained why that practice existed.

    >
    > The OP asked why the standadrs committee defined the semantics thus.
    >


    And I explained the reasons. By the way, you do not put those reasons
    in doubt apparently.

    1: Since stdout is line buffered it makes sense to put a new line
    character at the end of the string
    2: Since fputs would use a stream different than stdout or stderr
    those streams are not line buffered so the new line is not needed.

    3: In printf you want tight contro over the output so adding a new line
    to each printf would break most format instructions.

    Is there anything wrong with those explanations?

    Please explain.

    Thanks
     
    jacob navia, Jul 20, 2012
    #12
  13. writes:
    > Is there any logic behind puts() adding a newline but fputs() not doing it?
    > Or was it just a design f*** up in the early days of C?


    The C standard library is not a model of consistency, and I
    don't recall anyone claiming that it is. It evolved over a period
    of several years, and the committee had to standardize existing
    practice. (They could have invented a new and more consistent runtime
    library, but that would have hindered adoption of the standard.)

    My guess (and it's only a guess) is that puts() was designed first,
    and adding a newline to text written to stdout was thought to be
    convenient (and in fact it *is* convenient), and that fputs() was
    added later, and it was thought that having tighter control over
    what's written to a file was more important.

    Note that you can print a string to stdout either with or without
    an added newline:

    puts(s); /* adds newline */
    fputs(s, stdout); /* doens't add newline */

    We don't have the same option for files other than stdout, which
    is admittedly inconsistent; see above.

    Oh, and you might consider being less rude. The people who have
    responded to your question are simply trying to answer your question;
    reacting as if the inconsistency is their fault is not constructive.

    --
    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, Jul 20, 2012
    #13
  14. In article <>,
    Anders Wegge Keller <> wrote:

    > Mark Storkamp <> writes:
    >
    > > How is that different than what Jacob (with more patience than I
    > > have) explained? All you quoted was that it 'reflects existing
    > > practice'. Jacob explained why that practice existed.

    >
    > The OP asked why the standadrs committee defined the semantics thus.


    And the real answer to that is because the language pre dates the
    standard. They were documenting what already existed. Which really
    doesn't answer the question of why it is the way it is.
     
    Mark Storkamp, Jul 20, 2012
    #14
  15. jacob navia <> writes:

    > And I explained the reasons. By the way, you do not put those
    > reasons in doubt apparently.


    No, you made a *guess*. A plausible explanation, but nevertheless a
    *guess*. And then you tried to pass it on as fact.

    Mixing printf/fprintf in with puts/fputs, really made you look like
    grasping for straws, btw.

    --
    /Wegge

    Leder efter redundant peering af dk.*,linux.debian.*
     
    Anders Wegge Keller, Jul 20, 2012
    #15
  16. Philip Lantz Guest

    Anders Wegge Keller wrote:
    >
    > Mark Storkamp <> writes:
    >
    > > How is that different than what Jacob (with more patience than I
    > > have) explained? All you quoted was that it 'reflects existing
    > > practice'. Jacob explained why that practice existed.

    >
    > The OP asked why the standards committee defined the semantics thus.


    No he didn't. He asked if there was any logic behind the functions
    behaving differently.

    Obviously, the standard committee defined them that way because it was
    existing practice. But that doesn't answer the original question, which
    was why they were implemented that way. Jacob's answers are reasonable
    ones, but I agree with those who say that they are just his guesses.

    I don't recall ever having seen a definitive answer.
     
    Philip Lantz, Jul 21, 2012
    #16
  17. בת×ריך ×™×•× ×©×™×©×™, 20 ביולי 2012 18:26:35 UTC+1, מ×ת Mark Storkamp:
    > In article &lt;&gt;,
    > And the real answer to that is because the language pre dates the
    > standard. They were documenting what already existed. Which really
    > doesn't answer the question of why it is the way it is.
    >

    Probaby made sense on the original system that C ran on.

    Nowadays I never use any text output function except printf() or fprintf().The overhead in printf("%s\n", str) is too trivial to worry about.
     
    Malcolm McLean, Jul 21, 2012
    #17
  18. Tim Rentsch Guest

    Keith Thompson <> writes:

    > writes:
    >> Is there any logic behind puts() adding a newline but fputs() not doing it?
    >> Or was it just a design f*** up in the early days of C?

    >
    > The C standard library is not a model of consistency, and I
    > don't recall anyone claiming that it is. [snip]


    This gets my vote for "Best in Thread" award. A model response.
     
    Tim Rentsch, Jul 21, 2012
    #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:
    387
  2. dave
    Replies:
    4
    Views:
    671
  3. Chad

    A question about fputs()

    Chad, Jun 22, 2008, in forum: C Programming
    Replies:
    17
    Views:
    669
    Keith Thompson
    Jun 23, 2008
  4. Michael Brooks
    Replies:
    22
    Views:
    411
    Rick DeNatale
    Mar 27, 2007
  5. Raj Singh
    Replies:
    4
    Views:
    142
    Ryan Ingram
    Jan 29, 2008
Loading...

Share This Page