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

 

[Pieter Droogendijk]

#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);

Definitely undefined behaviour if fopen() failed. Other than that, no.

ungetc('z', pf);

One ungetc() is guaranteed to work. So, no problem.

ch = getc(pf);

getc() returns an int. Implementation-defined behaviour might arise if
getc() fails and if a char is signed.

This because getc() returns EOF if it fails, which might not fit in
a char.
If chars are unsigned, the value will be EOF with CHAR_MAX+1 added to it
until the value can be represented in a char.
If chars are signed, and EOF cannot be represented in it, the resulting
value is implementation-defined. Part of the behaviour might be a raised
signal.

However, I don't know if getc() is allowed to fail if you just called
ungetc(). I don't think the standard makes any guarantees about this.

printf("ch = %c\n", ch);

printf() expects an unsigned char converted to an int. The conversion to
int is done automatically thanks to the default integer promotion rules,
but char is not guaranteed to be unsigned.

I believe this is undefined behaviour.

fclose(pf);

No problem with this.

 

[santosh]

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

int main(void){

char *file_name = "t1.txt";

An uninitialised pointer is being used here.

char ch;
FILE *pf = fopen(file_name, "r+");

fopen() is not checked for errors.

fputs("bla", pf);

Again, fputs() is not checked for failure.

ungetc('z', pf);

The first parameter of ungetc() is an int.
Again, no checking for failure.

ch = getc(pf);

getc() returns an int, but may also return EOF on error.

printf("ch = %c\n", ch);
fclose(pf);

fclose() isn't being checked for error.

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?

AFAICS, there should be no problems with fclose().
The problem in this program is with the use of a uninitialised
pointer at the start.

I tested it here and it crashes. It because of the uninitialised
pointer.
Either use a string literal or allocate space via malloc or use an
array
to hold the file name.

 

[Jordan Abel]

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+");

Whether it is possible to open a text file for updating is
implementation-defined. that said, this could have been "r+b" without
changing the essential meaning of your question.

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?

I can't think of a single line in there that invokes undefined
behavior... however, it's not clear to me whether the contents of the
file are well-defined afterwards.

 

[Jordan Abel]

Definitely undefined behaviour if fopen() failed. Other than that, no.


printf() expects an unsigned char converted to an int. The conversion to
int is done automatically thanks to the default integer promotion rules,
but char is not guaranteed to be unsigned.

'z' is guaranteed to be positive, as are all members of the basic
execution character set. In any case, it's not the issue he was looking
for an answer on.

I believe this is undefined behaviour.

You believe incorrectly.

so what about the contents of the file afterwards? I suspect this is
what he was wondering about.

 

[Jordan Abel]

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.

 

[Robert Gamble]

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+");

Undefined behavior for all following operations that use pf if fopen
returns NULL.

fputs("bla", pf);
ungetc('z', pf);

Undefined behavior for not calling fflush on a stream after performing
an output operation and before performing an input operation.

ch = getc(pf);

getc returns int.

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?

Check the return value of fopen and fflush(pf) after the call to fputs
and you should be alright.

Robert Gamble

 

[Antonio Contreras]

An uninitialised pointer is being used here.

I tested it here and it crashes. It because of the uninitialised
pointer.
Either use a string literal or allocate space via malloc or use an
array
to hold the file name.

That line declares a pointer to char and initializes it to point to a
string literal. How does this constitute a use of an uninitialized
pointer?

 

[santosh]

I stumbled upon the following code (stripped to the minimum)

Well, the following modified version of the code you posted works
here for me.
The output is:
ch = z

<snip>
#include <stdio.h>
#include <stdlib.h>

int main(void){

int ch;
FILE *pf;
if((pf = fopen("t1.txt", "w+"))==NULL)
{
puts("fopen() returned NULL...");
exit(EXIT_FAILURE);
}
if((fputs("bla", pf))==EOF)
{
puts("fputs() returned EOF...");
exit(EXIT_FAILURE);
}
ch = 'z';
fflush(pf);
if((ungetc(ch, pf))==EOF)
{
puts("ungetc() returned EOF...");
exit(EXIT_FAILURE);
}

ch = getc(pf);
if(ch==EOF)
{
puts("getc() returned EOF...");
exit(EXIT_FAILURE);
}

printf("ch = %c\n", ch);
if((fclose(pf))==-1)
{
puts("fclose() returned -1...");
exit(EXIT_FAILURE);
}
return 0;

}

 

[Richard Bos]

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

 

[Robert Gamble]

An uninitialised pointer is being used here.

What is your definition of initialized?

Robert Gamble

 

[santosh]

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]

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

 

[Friedrich Dominicus]

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

 

[Robert Gamble]

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

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]

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

 

[Friedrich Dominicus]

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

 

[Nick Keighley]

Friedrich Dominicus wrote:
The first parameter of ungetc() is an int.

and 'z' *is* an int

 

[Keith Thompson]

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

 

[Mark McIntyre]

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