473,326 Members | 2,173 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

A question about fputs()

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
Jun 27 '08 #1
27 4350
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
Jun 27 '08 #2
On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
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'?
Jun 27 '08 #3
Chad said:
On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
>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
Jun 27 '08 #4
On Jun 22, 7:03 pm, Chad <cdal...@gmail.comwrote:
On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
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 27 '08 #5
On Jun 22, 9:11 am, Richard Heathfield <r...@see.sig.invalidwrote:
Chad said:
On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
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."

Jun 27 '08 #6
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.invalidwrote:
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'.
Jun 27 '08 #7
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 ---
Jun 27 '08 #8
On Jun 22, 9:23 am, Joe Wright <joewwri...@comcast.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 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'.
Jun 27 '08 #9
On Sun, 22 Jun 2008 09:21:19 -0700 (PDT), Chad <cd*****@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.
Jun 27 '08 #10

"Chad" <cd*****@gmail.comwrote in message
news:03**********************************@y38g2000 hsy.googlegroups.com...
On Jun 22, 9:23 am, Joe Wright <joewwri...@comcast.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 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


Jun 27 '08 #11
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/>
Jun 27 '08 #12
Chad wrote:
On Jun 22, 9:11 am, Richard Heathfield <r...@see.sig.invalidwrote:
>Chad said:
>>On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
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/>
Jun 27 '08 #13
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
Jun 27 '08 #14
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
Jun 27 '08 #15
Daniel Pitts wrote:
Chad wrote:
>On Jun 22, 9:11 am, Richard Heathfield <r...@see.sig.invalidwrote:
>>Chad said:

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
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.
No. Three '\n' are written to stdout. Note puts() adds a '\n' of its own.
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?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jun 27 '08 #16
Chad <cd*****@gmail.comwrites:
On Jun 22, 9:23 am, Joe Wright <joewwri...@comcast.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.

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) ks***@mib.org <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"
Jun 27 '08 #17
On Jun 22, 11:49*am, Richard Heathfield <r...@see.sig.invalidwrote:
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'

?

Jun 27 '08 #18
Chad wrote:
On Jun 22, 11:49 am, Richard Heathfield <r...@see.sig.invalidwrote:
>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
Jun 27 '08 #19
Chad wrote:
On Jun 22, 11:49*am, Richard Heathfield <r...@see.sig.invalidwrote:
>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.

Jun 27 '08 #20
Joe Wright wrote:
Daniel Pitts wrote:
>Chad wrote:
>>On Jun 22, 9:11 am, Richard Heathfield <r...@see.sig.invalidwrote:
Chad said:

On Jun 22, 8:58 am, Richard Heathfield <r...@see.sig.invalidwrote:
>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.
No. Three '\n' are written to stdout. Note puts() adds a '\n' of its own.
Definitely three.
puts(""), outputs one line.

puts and fputs are different that way.

--
pete
Jun 27 '08 #21
santosh wrote:
No,fputs will not write the terminating null to the stream.
None of the stdio functions
which take a pointer to a string as an argument,
will write the string's null character to a stream.

--
pete
Jun 27 '08 #22
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.

--
pete
Jun 27 '08 #23
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.

Jun 27 '08 #24
Chad wrote:
Richard Heathfield <r...@see.sig.invalidwrote:
>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'?
No. What it will do is leave the actual output time undefined. To
ensure it occurs you can output a later \n, or call fflush on the
output file involved.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Jun 27 '08 #25
On Jun 22, 8:46 pm, Chad <cdal...@gmail.comwrote:
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.
Jun 27 '08 #26
Chad <cd*****@gmail.comwrites:
[...]
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) ks***@mib.org <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"
Jun 27 '08 #27
santosh <sa*********@gmail.comwrites:
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) ks***@mib.org <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"
Jun 27 '08 #28

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Michael T. Peterson | last post by:
I am trying to get the file referenced by the following url: http://waterdata.usgs.gov/wa/nwis/uv?dd_cd=01&dd_cd=02&format=rdb&period=1&site_no=12149000 I'm using parse_url to get the host,...
2
by: Phil Powell | last post by:
My class method insert_new() is supposed to create and populate a brand new XML file. However, the file exists but its contents are never placed into the newly-created file, the file always...
145
by: Sidney Cadot | last post by:
Hi all, In a discussion with Tak-Shing Chan the question came up whether the as-if rule can cover I/O functions. Basically, he maintains it can, and I think it doesn't. Consider two...
3
by: J Wang | last post by:
Dear, could you tell me about the usage of "##" in preprossor give me some simple examples. thanks. I just got the example from "dissection C" as follows:
11
by: Jackie | last post by:
Hi everyone, I'd like to know when and how signals are used (e.g. SIGFPE, SIGABRT, SIGTERM, SIGSEGV, SIGINT)? Thank you so much.
1
by: Yoni Rabinovitch | last post by:
Hi, We have a large code base of "regular" C++ code (not MFC, COM or ATL). With VC6.0, we used to compile the "regular" C++ code as static libraries (.lib files), and then we would link the...
4
by: yuyazhang | last post by:
Hello everyone! Today, I programed a program with c,but regrettly i didn't success; My programe is as follows: #include <stdio.h> int main() { FILE* pFile ; pFile = fopen("yuya.txt","wt");
5
by: matt | last post by:
This is a strange one but I've been stuck on it for days. Any help appreciated. THE PLAN: I've a database that I use a script to grab all the entries for a particular field. I then want to...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.