By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,855 Members | 1,838 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,855 IT Pros & Developers. It's quick & easy.

where wrong?how to correct?and why? thank you

P: n/a
wwj
void main()
{
char* p="Hello";
printf("%s",p);
*p='w';
printf("%s",p);
}
Nov 13 '05 #1
Share this Question
Share on Google+
28 Replies


P: n/a
wwj <ww*******@mail2.swjtu.edu.cn> scribbled the following:
void main()
This is a non-standard form of main(). There is no guarantee it will
work. Better use: int main(void)
{
char* p="Hello";
printf("%s",p);
*p='w';
printf("%s",p);
}


The assignment *p='w' modifies a string literal, causing undefined
behaviour. On most implementations, string literals reside in read-only
memory. Thus *p='w' can cause a segfault or something similar.
Try instead: char p[6]="Hello";

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"This is a personnel commuter."
- Train driver in Scientific American
Nov 13 '05 #2

P: n/a
In article <87*************************@posting.google.com> , wwj wrote:

Missing inclusion of <stdio.h>.
void main()
int main(void)
{
char* p="Hello";
printf("%s",p);
*p='w';
You're not allowed to change a string literal.
printf("%s",p);
Missing flushing of stdout and "return 0;".
}


Corrected:

#include <stdio.h>

int main(void)
{
char p[] = "Hello";
printf("%s\n", p);
p[0] = 'w';
printf("%s\n", p);
return 0;
}
--
Andreas Kähäri
Nov 13 '05 #3

P: n/a
On 7 Nov 2003 06:37:44 -0800, ww*******@mail2.swjtu.edu.cn (wwj)
wrote:
void main()
int main(void) !!!!!!
{
char* p="Hello";
char *p = "Hello";
Don't let char* fool you, keep the * on the variable.
printf("%s",p);
printf("%s\n", p);
*p='w';
No! You cannot write to the string literal, "Hello".
printf("%s",p);
Again, you forgot the \n newline char.
return 0;}


Nov 13 '05 #4

P: n/a
Mark A. Odell <no****@embeddedfw.com> scribbled the following:
On 7 Nov 2003 06:37:44 -0800, ww*******@mail2.swjtu.edu.cn (wwj)
wrote:
{
char* p="Hello";
char *p = "Hello";
Don't let char* fool you, keep the * on the variable.


Note to newbies: This is an entirely stylistic correction and will
not affect the produced program at all.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd
Nov 13 '05 #5

P: n/a
On 7 Nov 2003 14:46:45 GMT, Joona I Palaste <pa*****@cc.helsinki.fi>
wrote:
{
char* p="Hello";

char *p = "Hello";
Don't let char* fool you, keep the * on the variable.


Note to newbies: This is an entirely stylistic correction and will
not affect the produced program at all.


Unless you write:

char* pFoo, pBar, pBaz;

and expect to get three pointers to char.

Nov 13 '05 #6

P: n/a
Mark A. Odell <no****@embeddedfw.com> scribbled the following:
On 7 Nov 2003 14:46:45 GMT, Joona I Palaste <pa*****@cc.helsinki.fi>
wrote:
{
char* p="Hello";
char *p = "Hello";
Don't let char* fool you, keep the * on the variable.


Note to newbies: This is an entirely stylistic correction and will
not affect the produced program at all.

Unless you write: char* pFoo, pBar, pBaz; and expect to get three pointers to char.


That is true, but what I was talking about was strictly what you wrote
in "correction" of the OP's code. The definition above is equivalent
to:

char *pFoo, pBar, pBaz;

or to:
char
* pFoo
, pBar ,
pBaz ;

What matters is how many * there are and between which words they
occur. Whether they "bind" to the type words or the variable name
words is irrelevant.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"He said: 'I'm not Elvis'. Who else but Elvis could have said that?"
- ALF
Nov 13 '05 #7

P: n/a
Greetings.

In article <87*************************@posting.google.com> , wwj wrote:
void main()
int main(void)
{
char* p="Hello";
printf("%s",p);
You forgot to #include <stdio.h>.
*p='w';
You are not premitted to overwrite a string literal, which is what p points
to. You could solve this problem by making p and array and initializing it
with the string "hello":

char p[6] = "Hello";

(The array length is 6 because C requires strings to contain a special
end-of-string marker, or "null character".)
printf("%s",p);
Since this is the last output of the program, it needs to be followed by a
newline. Otherwise you invoke undefined behaviour. Try:

printf("%s\n", p);
}


You have ended main without returning a value. The preferred method for an
exit without errors is:

return EXIT_SUCCESS;

The EXIT_SUCCESS macro is #defined in the <stdlib.h> header, which you must
#include before you use it. Alternatively, you could just write

return 0;

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Nov 13 '05 #8

P: n/a
In <87*************************@posting.google.com> ww*******@mail2.swjtu.edu.cn (wwj) writes:
void main()
Here wrong.
{
char* p="Hello";
printf("%s",p);
Here wrong.
*p='w';
Here wrong.
printf("%s",p);
Here wrong.
}


Congratulations! With the exception of the braces, you got a single line
of code right, and even that line is not adequate for your purposes.

Do yourself a favour and read a C book.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #9

P: n/a
In <bo**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Mark A. Odell <no****@embeddedfw.com> scribbled the following:
On 7 Nov 2003 06:37:44 -0800, ww*******@mail2.swjtu.edu.cn (wwj)
wrote:
{
char* p="Hello";

char *p = "Hello";
Don't let char* fool you, keep the * on the variable.


Note to newbies: This is an entirely stylistic correction and will
not affect the produced program at all.


It will, once the newbie writes:

char* p, q;

and expects the declaration to have the "obvious" meaning.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #10

P: n/a
On Fri, 07 Nov 2003 16:22:07 +0000, wwj wrote:
On Fri, 07 Nov 2003 15:23:03 GMT, "Dan Pop" said:

Do you actually contribute anything here, or do you just repost advice that
others have already given?


No, I don't think "Dan Pop" actually wrote that.
Please attribute correctly and don't top post. Thanks.
Nov 13 '05 #11

P: n/a
wwj <ww*******@mail2.swjtu.edu.cn> scribbled the following:
On Fri, 07 Nov 2003 15:23:03 GMT, "Dan Pop" said:
Do you actually contribute anything here, or do you just repost advice that
others have already given?


You're new here, aren't you? Dan Pop is one of the most clueful people
here. He is not always polite but he is nearly always right. He has
answered a great deal of questions here, even more than I have. Just
because he reposts *one* piece of advice that's already been given
doesn't mean he never contributes anything.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen
Nov 13 '05 #12

P: n/a
wwj <ww*******@mail2.swjtu.edu.cn> wrote:

[top-posting fixed; please don't top-post; thank you]
On Fri, 07 Nov 2003 15:23:03 GMT, "Dan Pop" said:
In <bo**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:
Mark A. Odell <no****@embeddedfw.com> scribbled the following:
On 7 Nov 2003 06:37:44 -0800, ww*******@mail2.swjtu.edu.cn (wwj)
wrote:
>{
> char* p="Hello";

char *p = "Hello";
Don't let char* fool you, keep the * on the variable.

Note to newbies: This is an entirely stylistic correction and will
not affect the produced program at all.


It will, once the newbie writes:

char* p, q;

and expects the declaration to have the "obvious" meaning.


Do you actually contribute anything here, or do you just repost advice that
others have already given?


I'd like to ask you some questions:

Do you actually now how usenet works? Do you now what off-line reading
means? Did you ever notice that propagation of messages is a non-linear
process? What is wrong with two people making a similar remark,
especially if it's correct? Did you ever read any more messages by Dan
Pop than the one you just responded to?

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #13

P: n/a
*** Rude top-posting corrected ***

wwj wrote:
On Fri, 07 Nov 2003 15:23:03 GMT, "Dan Pop" said:
Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Mark A. Odell <no****@embeddedfw.com> scribbled the following:
ww*******@mail2.swjtu.edu.cn (wwj) wrote:
>
>{
> char* p="Hello";

char *p = "Hello";
Don't let char* fool you, keep the * on the variable.

Note to newbies: This is an entirely stylistic correction and
will not affect the produced program at all.


It will, once the newbie writes:

char* p, q;

and expects the declaration to have the "obvious" meaning.


Do you actually contribute anything here, or do you just repost
advice that others have already given?


Congratulations. You have just rudely contravened standard
practice here by top-posting, and gratuitously insulted one of the
more knowledgeable participants, who in turn is not noted for his
gentle handling of fools, nor for his diplomatic skills. You
contrived to do all this in only two lines. This is a well tested
method of attracting future help.

In the likely case that you are too mentally challenged to
recognize it, you have just been flamed and insulted. A
productive response would be abject apology and grovelling.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 13 '05 #14

P: n/a
On Fri, 7 Nov 2003, CBFalconer wrote:

[Talking about Dan Pop.]
one of the
more knowledgeable participants, who in turn is not noted for his
gentle handling of fools, nor for his diplomatic skills.


I think his diplomatic skills have improved significantly
during the past two years. :-)

Tak-Shing, biased sampling

Nov 13 '05 #15

P: n/a
"Tristan Miller" <ps********@nothingisreal.com> wrote in message
news:19****************@ID-187157.news.dfncis.de...
Greetings.

In article <87*************************@posting.google.com> , wwj wrote:
void main()
int main(void)
{
char* p="Hello";
printf("%s",p);


You forgot to #include <stdio.h>.
*p='w';


You are not premitted to overwrite a string literal, which is what p

points to. You could solve this problem by making p and array and initializing it with the string "hello":

char p[6] = "Hello";

(The array length is 6 because C requires strings to contain a special
end-of-string marker, or "null character".)


That's all true, but why to count (and eventually not re-count)
if compiler does the grunt work? Right, Joona?

char p[] = "Hello";
printf("%s",p);


Since this is the last output of the program, it needs to be followed by a
newline. Otherwise you invoke undefined behaviour.


Undefined? It's not even unintended. *Because* it is
"last output of the program".
[N869]
7.19.3 Files
....
5 ... If the main function returns to its original caller,
or if the exit function is called, all open files are
closed (hence all output streams are flushed) before
program termination. Other paths to program termination,
such as calling the abort function, need not close all
files properly.

[snip]
Nov 13 '05 #16

P: n/a
nobody wrote:

"Tristan Miller" <ps********@nothingisreal.com> wrote in message
news:19****************@ID-187157.news.dfncis.de...
Greetings.

In article <87*************************@posting.google.com> ,
wwj wrote:
printf("%s",p);


Since this is the last output of the program,
it needs to be followed by a newline.
Otherwise you invoke undefined behaviour.


Undefined?


N869
7.19.2 Streams
[#2]
Whether the last line requires
a terminating new-line character
is implementation-defined.

--
pete
Nov 13 '05 #17

P: n/a
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
nobody wrote:

"Tristan Miller" <ps********@nothingisreal.com> wrote in message
news:19****************@ID-187157.news.dfncis.de...
Greetings.

In article <87*************************@posting.google.com> ,
wwj wrote: printf("%s",p);

Since this is the last output of the program,
it needs to be followed by a newline.
Otherwise you invoke undefined behaviour.


Undefined?


N869
7.19.2 Streams
[#2]
Whether the last line requires
a terminating new-line character
is implementation-defined.

So ... does it mean that absence of '\n' invokes undefined
behaviour? Or it's presence? From your citation then, it would
seem that whatever you do, you can't have truly portable program,
if you are sending "data" to stdout/stderr. But I must be wrong,
so what did I miss? Why was my citation irrelevant to the case?
Nov 13 '05 #18

P: n/a
nobody wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
nobody wrote:

"Tristan Miller" <ps********@nothingisreal.com> wrote in message
news:19****************@ID-187157.news.dfncis.de...
> Greetings.
>
> In article <87*************************@posting.google.com> ,
> wwj wrote:
> > printf("%s",p);
>
> Since this is the last output of the program,
> it needs to be followed by a newline.
> Otherwise you invoke undefined behaviour.

Undefined?


N869
7.19.2 Streams
[#2]
Whether the last line requires
a terminating new-line character
is implementation-defined.

So ... does it mean that absence of '\n' invokes undefined
behaviour?


It means that if the stream is not terminated with a newline,
that the code is not portable.
On a system which defines a stream as ending in a newline,
if you have something that's just like a stream,
except for the way that it's terminated, then it's not a stream,
and it isn't defined.
Or it's presence? From your citation then, it would
seem that whatever you do, you can't have truly portable program,
if you are sending "data" to stdout/stderr.
All you have to do, is make sure that the last output character
to the standard output stream, is a null character, to be portable.
But I must be wrong,
so what did I miss? Why was my citation irrelevant to the case?


Because it has nothing to do with whether or not the last output
character in a text stream should be a null character.

--
pete
Nov 13 '05 #19

P: n/a
pete wrote:

nobody wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
nobody wrote:
>
> "Tristan Miller" <ps********@nothingisreal.com> wrote in message
> news:19****************@ID-187157.news.dfncis.de...
> > Greetings.
> >
> > In article <87*************************@posting.google.com> ,
> > wwj wrote:

> > > printf("%s",p);
> >
> > Since this is the last output of the program,
> > it needs to be followed by a newline.
> > Otherwise you invoke undefined behaviour.
>
> Undefined?

N869
7.19.2 Streams
[#2]
Whether the last line requires
a terminating new-line character
is implementation-defined.
So ... does it mean that absence of '\n' invokes undefined
behaviour?


It means that if the stream is not terminated with a newline,
that the code is not portable.
On a system which defines a stream as ending in a newline,
if you have something that's just like a stream,
except for the way that it's terminated, then it's not a stream,
and it isn't defined.
Or it's presence? From your citation then, it would
seem that whatever you do, you can't have truly portable program,
if you are sending "data" to stdout/stderr.


All you have to do, is make sure that the last output character
to the standard output stream, is a null character, to be portable.


I meant "newline" instead of "null"
But I must be wrong,
so what did I miss? Why was my citation irrelevant to the case?


Because it has nothing to do with whether or not the last output
character in a text stream should be a null character.


I meant "newline" instead of "null"

--
pete
Nov 13 '05 #20

P: n/a
pete <pf*****@mindspring.com> wrote in message news:<3F***********@mindspring.com>...
[snip]
> N869
> 7.19.2 Streams
> [#2]
> Whether the last line requires
> a terminating new-line character
> is implementation-defined.
>
So ... does it mean that absence of '\n' invokes undefined
behaviour?


It means that if the stream is not terminated with a newline,
that the code is not portable.
On a system which defines a stream as ending in a newline,
if you have something that's just like a stream,
except for the way that it's terminated, then it's not a stream,
and it isn't defined.
Or it's presence? From your citation then, it would
seem that whatever you do, you can't have truly portable program,
if you are sending "data" to stdout/stderr.


All you have to do, is make sure that the last output character
to the standard output stream, is a null character, to be portable.


I meant "newline" instead of "null"
But I must be wrong,
so what did I miss? Why was my citation irrelevant to the case?


Because it has nothing to do with whether or not the last output
character in a text stream should be a null character.


I meant "newline" instead of "null"


Hi everyone, while going through this I was just brushing over that
section of the standard and am quite interested in your comments
regarding the following
citation :

7.19.2 Streams

3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation. Such a stream may,however, have
an *implementation-defined number of null characters* appended to the
end of the stream.

Does this mean that a strictly conforming program is unable to
create or use a binary stream because if it assumes a certain no. of
null characters at the end of the stream, this no. may change from
implementation to implementation? Of course fseek can always be used
..... but we cannot rely on the no. of nulls at the end of the stream?
Am I correct? Or am I missing something.
Thanks everyone.. I'll be eagerly awaiting your comments. Actually
This was because even the limitation regarding a newline at the end of
a stream was new to me and I enjoyed this beautiful piece of
information. Also I discovered something else I did not know. Just
sharing it with you all (Though many of you must be already knowing
this fact). It's that as per #2 of 1.19.2 , a space before a newline
is not guaranteed to be read in correctly. That too was news to me.
Thanks and regards,
Anupam

PS. I'd like to suggest all the newcomers to refrain from making
strong comments too fast. I'm also not too old to this group. I find
that I enjoy it immensely, because here people really do know. Use
their expertise and give of whatever you have but dont get into a
slanging contest. My first posting was a bad off-topic one .. albeit I
was thinking that I was doing a right thing by correcting the trolls
... but its no good to feed them.. better by far to ignore them all ...
hang around for a while and then it becomes easy to understand about
the internalisations of the between-the-lines facts of the group.
Thanks
Nov 13 '05 #21

P: n/a
In article <aa**************************@posting.google.com >
Anupam <an**************@persistent.co.in> writes:
... I was just brushing over that
section of the standard and am quite interested in your comments
regarding the following
citation :

7.19.2 Streams

3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation. Such a stream may,however, have
an *implementation-defined number of null characters* appended to the
end of the stream.

Does this mean that a strictly conforming program is unable to
create or use a binary stream because if it assumes a certain no. of
null characters at the end of the stream, this no. may change from
implementation to implementation? Of course fseek can always be used
.... but we cannot rely on the no. of nulls at the end of the stream?


A strictly conforming program can still create or use a binary
stream, provided it makes no assumptions about such null bytes.

This restriction comes from real-world operating systems, including
both VMS and MS-DOS. On these systems, some files come in "fixed
length record" format, typically an exact multiple of 512 bytes
long[%]. If you write 510 bytes to such a binary file, then close
it, then open it and read it back, you will see that the file
contains 512 bytes. The last two, as long as the file is both
written and then read-back in C, must be '\0' (in other languages
they could conceivably have other values). Write 513 bytes, and
this file will be 1024 bytes long, the last 511 of them being '\0'.
-----
[%] The fixed record size is not necessarily 512 -- 1024 and
2048 are not terribly uncommon, and 256 and 128 did occur;
and even non-powers-of-two are possible sometimes. But 512
is by far the most common number.
-----

On some of these file systems, text files are (or were once) also
exact multiples of 512 bytes long. To tell where a text file should
*appear* to end, the I/O library appends a special "end-of-file"
marker character, often a control-Z ('\034') byte. Reading any
file -- including a binary file -- "as if" it were text then returns
EOF when the marker is encountered. Contrariwise, reading a text
file in binary allows you to "read past the end". (VMS's RMS is
too smart to allow you to read a file in the wrong mode by mistake.
MS-DOS is pretty stupid and will let you do whatever you like.
It inherited this from CP/M and QDOS, from which it was cloned.
Current DOS file system formats as used on Windows do specify file
sizes in bytes, but the now-pointless control-Z protocol is often
retained anyway.)

As a quick (if not terribly efficient) illustration of how one can
deal with '\0' padding in binary files, imagine that your C code
to write a block of binary data to a binary file is coded as:

void write_a_block(unsigned char *data, size_t len) {
size_t written;

written = fwrite(data, 1, size, output_file);
if (written != size)
... handle output error ...
}

If you fopen some file for "wb", call write_a_block several times,
then fclose the file, the file may have '\0' bytes appended, so
there is no way to read the file back without possibly getting
those extra '\0' bytes. But suppose we change write_a_block() to
read:

void write_a_block(unsigned char *data, size_t len) {
size_t written;
unsigned long l;
unsigned char b[4];

if (len == 0)
... handle "asked to write 0 bytes" error ...
if (len > 0xffffffffU)
... handle block-too-big error ...
l = len; /* we use l in case size_t is < 32 bits long */
b[0] = l >> 24; /* mask not necessary: we know l <= 0xffffffff */
b[1] = (l >> 16) & 0xff;
b[2] = (l >> 8) & 0xff;
b[3] = l & 0xff;
written = fwrite(b, 1, 4, output_file);
if (written != 4)
... handle output error ...
written = fwrite(data, 1, size, output_file);
if (written != size)
... handle output error ...
}

Now each block in the file is prefixed with a (nonzero) big-endian
count of the number of bytes in the block. To read the file back,
first read four "unsigned char"s, then assemble the desired length:

nread = fread(b, 1, 4, input_file);
if (nread != 4)
... handle input eof/error ...
l = ((unsigned long)b[0] << 24) +
((unsigned long)b[1] << 16) +
((unsigned long)b[2] << 8) +
(unsigned long)b[3];
if (l > (size_t)-1)
... handle block-too-big error ...
... now fread "l" bytes, as before ...

(The "block-too-big" error can occur if the file is written on
system X, where size_t is a 32-bit unsigned value and the block
is, say, 1048576 bytes -- 1 megabyte -- long, but is to be read
back on system Y, where size_t is a 16-bit unsigned value and can
only count to 65535. This test can be omitted if you are certain
that no blocks will be "too big" this way.)

A file that has '\0' bytes appended will cause l to be 0, because
b[0] through b[3] will all be '\0', which is 0. So instead of
fread()ing "l" bytes, we can check for this. Of course, we must
also handle the condition where nread < 4 (or even is 0) if
this is the last block, so the above code has to read more like
this:

size_t i, nread;
unsigned long l;

nread = fread(b, 1, 4, input_file);
for (i = 0; i < nread && b[i] == '\0'; i++)
continue;
if (i == nread)
... handle input EOF ...
if (nread < 4)
... handle input error ...
/* build and handle l as before */

Any number of other binary file formats can be designed. To make
it possible to use such files on any hosted C system, however, the
design must account for the possibility of extra '\0' bytes added
to these files. If anyone ever decides to port your code to an
old mainframe, they will be glad you considered this. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #22

P: n/a
an**************@persistent.co.in (Anupam) wrote:
pete <pf*****@mindspring.com> wrote:
nobody wrote:
> pete wrote: [snip] > > N869
> > 7.19.2 Streams
> > [#2]
> > Whether the last line requires
> > a terminating new-line character
> > is implementation-defined.
> >
> So ... does it mean that absence of '\n' invokes undefined
> behaviour?

It means that if the stream is not terminated with a newline,
that the code is not portable.
On a system which defines a stream as ending in a newline,
if you have something that's just like a stream,
except for the way that it's terminated, then it's not a stream,
and it isn't defined.
<snip> Hi everyone, while going through this I was just brushing over that
section of the standard and am quite interested in your comments
regarding the following
citation :

7.19.2 Streams

3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation. Such a stream may,however, have
an *implementation-defined number of null characters* appended to the
end of the stream.

Does this mean that a strictly conforming program is unable to
create or use a binary stream because if it assumes a certain no. of
null characters at the end of the stream, this no. may change from
implementation to implementation?
As binary streams have implementation-defined properties, any program
that produces output dependent on binary streams is not strictly
conforming.
Of course fseek can always be used
.... but we cannot rely on the no. of nulls at the end of the stream?
Am I correct? Or am I missing something.
ISO/IEC 9899:TC1 7.19.9.2#3:
[...] A binary stream need not meaningfully support fseek calls with a
whence value of SEEK_END.
Thanks everyone.. I'll be eagerly awaiting your comments. Actually
This was because even the limitation regarding a newline at the end of
a stream was new to me and I enjoyed this beautiful piece of
information. Also I discovered something else I did not know. Just
sharing it with you all (Though many of you must be already knowing
this fact). It's that as per #2 of 1.19.2 , a space before a newline
is not guaranteed to be read in correctly. That too was news to me.


ITYM 7.19.2#2; there is no section 1.19.2 in either C89 or C99.

<snip>

Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #23

P: n/a
Irrwahn Grausewitz <ir*******@freenet.de> wrote:
As binary streams have implementation-defined properties, any program
that produces output dependent on binary streams is not strictly
conforming. ^^^^^^^^^^^^^^^^^


Should read: ... on these properties of binary streams ...
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #24

P: n/a
Irrwahn Grausewitz <ir*******@freenet.de> wrote in message news:<fp********************************@4ax.com>. ..
Thanks everyone.. I'll be eagerly awaiting your comments. Actually
This was because even the limitation regarding a newline at the end of
a stream was new to me and I enjoyed this beautiful piece of
information. Also I discovered something else I did not know. Just
sharing it with you all (Though many of you must be already knowing
this fact). It's that as per #2 of 1.19.2 , a space before a newline
is not guaranteed to be read in correctly. That too was news to me.
ITYM 7.19.2#2; there is no section 1.19.2 in either C89 or C99.

Yup that was a typo, sorry about that.
<snip>

Regards

Nov 13 '05 #25

P: n/a
In <aa**************************@posting.google.com > an**************@persistent.co.in (Anupam) writes:
Hi everyone, while going through this I was just brushing over that
section of the standard and am quite interested in your comments
regarding the following
citation :

7.19.2 Streams

3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation. Such a stream may,however, have
an *implementation-defined number of null characters* appended to the
end of the stream.

Does this mean that a strictly conforming program is unable to
create or use a binary stream because if it assumes a certain no. of
null characters at the end of the stream, this no. may change from
implementation to implementation?
Nope. Divide the file between a fixed length header part and a variable
length data part. If the header contains the length of the data part,
you know exactly what is the last byte of the file that was actually
written by your program and you can safely ignore any bytes that might
be following it.

OTOH, it doesn't make much sense to talk about strictly conforming
programs in the context of I/O: any I/O request may fail for unspecified
reasons and, if your program's output is affected by such failures, your
program is no longer strictly conforming. OTOH, what's the point of
reading data from files if the program's output is not going to be
affected by it? ;-)
Of course fseek can always be used
.... but we cannot rely on the no. of nulls at the end of the stream?


fseek is useless if you want to go at the end of a binary stream.
However, if you use the above described approach (or if you know how
many bytes have been written to the binary file by the program creating
it, in advance), you can easily fseek to the last byte of data written
to the file by the program that created it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #26

P: n/a
pete wrote:

nobody wrote:

"Tristan Miller" <ps********@nothingisreal.com> wrote in message
news:19****************@ID-187157.news.dfncis.de...
Greetings.

In article <87*************************@posting.google.com> ,
wwj wrote: printf("%s",p);

Since this is the last output of the program,
it needs to be followed by a newline.
Otherwise you invoke undefined behaviour.


Undefined?


N869
7.19.2 Streams
[#2]
Whether the last line requires
a terminating new-line character
is implementation-defined.

Non sequitur.

The newline on the output (text) stream is meant to ensure the buffered
stream gets sent to the output device.

The newline on the input (text) stream simply terminates a line.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '05 #27

P: n/a
"Joe Wright" <jo********@earthlink.net> wrote:
pete wrote:
nobody wrote:
N869
7.19.2 Streams
[#2]
Whether the last line requires
a terminating new-line character
is implementation-defined.
Non sequitur.

The newline on the output (text) stream is meant to
ensure the buffered stream gets sent to the output device.


Not just that -- it's also to ensure that the stream is
terminated correctly and therefore is valid as a whole.
Remember that streams like stdout need not be interactive,
and in the worst case the user may lose the whole contents
of the stream if the last line is not terminated correctly!
The newline on the input (text) stream simply terminates
a line.


Input streams are beyond the control of the C program so
the validity issue doesn't really come up -- I would just
assume that the implementation will give you a stream that
it considers valid.

--
Simon.
Nov 13 '05 #28

P: n/a
In article <Pine.GSO.4.33.0311071852050.14685-100000@swindon>, es728
@city.ac.uk says...
On Fri, 7 Nov 2003, CBFalconer wrote:

[Talking about Dan Pop.]
one of the
more knowledgeable participants, who in turn is not noted for his
gentle handling of fools, nor for his diplomatic skills.


I think his diplomatic skills have improved significantly
during the past two years. :-)

Tak-Shing, biased sampling


Now why in the world did you have to say that? He's going to read it
and adjust his style accordingly. *sigh*

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.