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.

[santosh]

Friedrich Dominicus 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"; 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.

[Pieter Droogendijk]

On Thu, 15 Dec 2005 14:19:26 +0100, Friedrich Dominicus wrote:

#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.
return 0;
}

--
Pieter Droogendijk <pieter at binky dot org dot uk>
PGP/1E92DBBC [ Make way for the Emperor's Finest. ] binky.org.uk

[Jordan Abel]

On 2005-12-15, 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+");
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]

On 2005-12-15, Pieter Droogendijk <pi******@binky SPAM.orgFOR.ukM E> wrote:

On Thu, 15 Dec 2005 14:19:26 +0100, Friedrich Dominicus wrote:

#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);
ch = getc(pf);
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.

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

fclose(pf);
return 0;
}

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

[Jordan Abel]

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.

[Robert Gamble]

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

santosh wrote:

Friedrich Dominicus 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"; An uninitialised pointer is being used here.

<snip part of the answer>
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]

Friedrich Dominicus wrote:

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+"))==NUL L)
{
puts("fopen() returned NULL...");
exit(EXIT_FAILU RE);
}
if((fputs("bla" , pf))==EOF)
{
puts("fputs() returned EOF...");
exit(EXIT_FAILU RE);
}
ch = 'z';
fflush(pf);
if((ungetc(ch, pf))==EOF)
{
puts("ungetc() returned EOF...");
exit(EXIT_FAILU RE);
}

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

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

}

[Robert Gamble]

santosh wrote:

Friedrich Dominicus 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";

An uninitialised pointer is being used here.

What is your definition of initialized?

Robert Gamble