A question about fputs()

[Chad]

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

[Richard Heathfield]

Re: A question about fputs()

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/.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chad]

Re: A question about fputs()

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

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'?

[Richard Heathfield]

Re: A question about fputs()

Chad said:

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

>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'?

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 between null
bytes and newlines, it doesn't work - newlines are a fundamental part of
text streams, whereas null bytes are not.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[vippstar@gmail.com]

Re: A question about fputs()

On Jun 22, 7:03 pm, Chad <cdal...@gmail. comwrote:

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.i nvalidwrote:
>

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) .

[Chad]

Re: A question about fputs()

On Jun 22, 9:11 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

Chad said:
>
>
>

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

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, whereasnullbyte s 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]

Re: A question about fputs()

On Jun 22, 9:10 am, vipps...@gmail. com wrote:

On Jun 22, 7:03 pm, Chad <cdal...@gmail. comwrote:
>
>
>

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

>

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 likefputs
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'.

[Joe Wright]

Re: A question about fputs()

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

The ascii character NUL 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 control character used to define a string in memory. It is
not part of the data read with fgets() or written with fputs().

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Chad]

Re: A question about fputs()

On Jun 22, 9:23 am, Joe Wright <joewwri...@com cast.netwrote:

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 asciicharacterN UL 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 controlcharacte rused 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'.

[Raymond Martineau]

Re: A question about fputs()

On Sun, 22 Jun 2008 09:21:19 -0700 (PDT), Chad <cdalten@gmail. com>
wrote:

>On Jun 22, 9:10 am, vipps...@gmail. com wrote:

>On Jun 22, 7:03 pm, Chad <cdal...@gmail. comwrote:
>>

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.

[Bartc]

Re: A question about fputs()


"Chad" <cdalten@gmail. comwrote in message
news:0338a30b-63e4-4501-b9aa-3f5c4abd6358@y3 8g2000hsy.googl egroups.com...

On Jun 22, 9:23 am, Joe Wright <joewwri...@com cast.netwrote:

>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 asciicharacterN UL 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 controlcharacte rused 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

[Daniel Pitts]

Re: A question about fputs()

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]

Re: A question about fputs()

Chad wrote:

On Jun 22, 9:11 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

>Chad said:
>>
>>
>>

>>On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.i nvalidwrote:
>>>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/>

[Richard Heathfield]

Re: A question about fputs()

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?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Re: A question about fputs()

Chad said:

<snip>

>
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'.

Why would it include the trailing '\0'? That's just a sentinel, an
end-marker; it is not part of the string data.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999