undefined behaviour?

[Friedrich Dominicus]

I stumbled upon the following code (stripped to the minimum)
#include <stdio.h>
#include <stdlib.h>

int main(void){

char *file_name = "t1.txt";
char ch;
FILE *pf = fopen(file_name , "r+");
fputs("bla", pf);
ungetc('z', pf);
ch = getc(pf);
printf("ch = %c\n", ch);
fclose(pf);
return 0;
}

Now I'm wondering if this is defined behaviour or not, and if it's
defined should there be a problem with the close at the end?

Thanks in advance
Friedrich

--
Please remove just-for-news- to reply via e-mail.

[Richard Bos]

Friedrich Dominicus <ju************ *****@q-software-solutions.de> wrote:

I stumbled upon the following code (stripped to the minimum)
#include <stdio.h>
#include <stdlib.h>

int main(void){

char *file_name = "t1.txt";
char ch;
FILE *pf = fopen(file_name , "r+");
fputs("bla", pf);
ungetc('z', pf);

Yes, undefined behaviour. You just wrote (using fputs()) to an update
stream, causing it to be set to output mode. ungetc() expects an input
stream. You cannot use ungetc() on an output-oriented update stream
without first using fflush() or a file positioning function.

This raises the question of what happens when you fflush() between
fputs() and ungetc(). AFAICT, that should work, not cause UB, cause the
'z' to be read by the following getc(), and as the Standard says about
ungetc(): "The external storage corresponding to the stream is
unchanged".

Richard

[santosh]

Jordan Abel wrote:

On 2005-12-15, santosh <sa*********@gm ail.com> wrote:

char *file_name = "t1.txt";

An uninitialised pointer is being used here.

The line you are responding to is a declaration, and, moreover, one with
an initializer.

You claim that on your implementation the program crashes on that line.
Either you're lying, or you have a very crappy [and non-conforming]
implementation.

Your right. I'm sorry. It was an incredible oversight on my part.

That being said, the code as was posted did crash over here.
The compiler is gcc (mingw).
After I introduced error checking for each function call I found that
the
first error was with foen().
I modified "r+" to "w+" which succeeded, but then ungetc() returned
EOF.
I corrected that by inserting a 'fflush(pf)' before calling ungetc().
Then it was getc()'s turn to return EOF.
After I changed 'ch' from char to int the program finally executed as
it
should. The contents of the file after running the code is:
bla [Hex dump = 626c 610d 0a]

[Friedrich Dominicus]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Friedrich Dominicus <ju************ *****@q-software-solutions.de> wrote:

I stumbled upon the following code (stripped to the minimum)
#include <stdio.h>
#include <stdlib.h>

int main(void){

char *file_name = "t1.txt";
char ch;
FILE *pf = fopen(file_name , "r+");
fputs("bla", pf);
ungetc('z', pf);
Yes, undefined behaviour. You just wrote (using fputs()) to an update
stream, causing it to be set to output mode. ungetc() expects an input
stream.

Well that's what the 'r' is for or not? So for me it's an input stream
in first line and writable also.
You cannot use ungetc() on an output-oriented update stream
without first using fflush() or a file positioning function.

As posted before I can understand this argument, and as said before I
have found it out there, but was puzzling about its validity.

Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.

[Friedrich Dominicus]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

This raises the question of what happens when you fflush() between
fputs() and ungetc(). AFAICT, that should work, not cause UB, cause the
'z' to be read by the following getc(), and as the Standard says about
ungetc(): "The external storage corresponding to the stream is
unchanged".

So I'd argue it's defined if there is an fflush between the fputs and
ungetc, and undefined without it. That's sounds reasonable

Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.

[Robert Gamble]

Friedrich Dominicus wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Friedrich Dominicus <ju************ *****@q-software-solutions.de> wrote:

I stumbled upon the following code (stripped to the minimum)
#include <stdio.h>
#include <stdlib.h>

int main(void){

char *file_name = "t1.txt";
char ch;
FILE *pf = fopen(file_name , "r+");
fputs("bla", pf);
ungetc('z', pf);

Yes, undefined behaviour. You just wrote (using fputs()) to an update
stream, causing it to be set to output mode. ungetc() expects an input
stream.

Well that's what the 'r' is for or not? So for me it's an input stream
in first line and writable also.

You cannot use ungetc() on an output-oriented update stream
without first using fflush() or a file positioning function.

As posted before I can understand this argument, and as said before I
have found it out there, but was puzzling about its validity.

Here is the appropriate section of the Standard (n1124 to be exact):

7.19.5.3p6

When a file is opened with update mode ('+' as the second or third
character in the
above list of mode argument values), both input and output may be
performed on the
associated stream. However, output shall not be directly followed by
input without an
intervening call to the fflush function or to a file positioning
function (fseek,
fsetpos, or rewind), and input shall not be directly followed by output
without an
intervening call to a file positioning function, unless the input
operation encounters endof-
file. Opening (or creating) a text file with update mode may instead
open (or create) a
binary stream in some implementations .

I hope that relieves any doubt you had about the validity of the
statements made to that effect here.

Robert Gamble

[Friedrich Dominicus]

"santosh" <sa*********@gm ail.com> writes:

Jordan Abel wrote:

On 2005-12-15, santosh <sa*********@gm ail.com> wrote:

>> char *file_name = "t1.txt";
> An uninitialised pointer is being used here.
The line you are responding to is a declaration, and, moreover, one with
an initializer.

You claim that on your implementation the program crashes on that line.
Either you're lying, or you have a very crappy [and non-conforming]
implementation.

Your right. I'm sorry. It was an incredible oversight on my part.

That being said, the code as was posted did crash over here.
The compiler is gcc (mingw).
After I introduced error checking for each function call I found that
the
first error was with foen().

Well that does not mean that the code as given was invalid
I modified "r+" to "w+" which succeeded, but then ungetc() returned
EOF. That's interesting and I think that should not happen, even if you use
"r+". I corrected that by inserting a 'fflush(pf)' before calling
ungetc(). I'd argue this is the real problem.

The system as used her has worked fine but baild out on the fclose at
the end. After insering the fflush here this was gone and the result
were as expected.
After I changed 'ch' from char to int the program finally executed as
it I don't think this is really a problem. should. The contents of the file after running the code is:

Can't tell I did not care about the content just the fputs + ungetc
stuff. However thanks for taking the time checking all this "stuff"

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

[Friedrich Dominicus]

"Robert Gamble" <rg*******@gmai l.com> writes:

Here is the appropriate section of the Standard (n1124 to be exact):

7.19.5.3p6

When a file is opened with update mode ('+' as the second or third
character in the
above list of mode argument values), both input and output may be
performed on the
associated stream. However, output shall not be directly followed by
input without an
intervening call to the fflush function or to a file positioning
function (fseek,
fsetpos, or rewind), and input shall not be directly followed by output
without an
intervening call to a file positioning function, unless the input
operation encounters endof-
file. Opening (or creating) a text file with update mode may instead
open (or create) a
binary stream in some implementations .

I hope that relieves any doubt you had about the validity of the
statements made to that effect here.

Well that is the "definitive " answer for me. I have not seen
it. Thanks for pointing it out to me.

Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.

[Nick Keighley]

santosh wrote:

Friedrich Dominicus wrote:

ungetc('z', pf);

The first parameter of ungetc() is an int.

and 'z' *is* an int
--
Nick Keighley

[Keith Thompson]

"Nick Keighley" <ni************ ******@hotmail. com> writes:

santosh wrote:

Friedrich Dominicus wrote:

> ungetc('z', pf);

The first parameter of ungetc() is an int.

and 'z' *is* an int

And even if it weren't, it would be implicitly converted to int (since
there's a "#include <stdio.h>").

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Thu, 15 Dec 2005 16:14:21 +0100, in comp.lang.c , Friedrich
Dominicus <ju************ *****@q-software-solutions.de> wrote:

You cannot use ungetc() on an output-oriented update stream
without first using fflush() or a file positioning function.

As posted before I can understand this argument, and as said before I
have found it out there, but was puzzling about its validity.

Its in the Standard.

7.19.5.3(6) When a file is opened with update mode ... output shall
not be directly followed by input without an intervening call to the
fflush function or to a file positioning function..., and input shall
not be directly followed by output without an intervening call to a
file positioning function...

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----