Dumb Question.

[vashwath]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?Is it possible to read
from a file which already closed at least once out of 1000 times on
thousand different environment?

 

[Nick Keighley]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

it's a good idea to check the return value of fopen(). It is an even
better idea to
initialise fp before you use it...

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?

it really is a bad idea to expect anything from Undefined Behaviour.
Long
ago on this ng a poster said he had actually been asked by the computer

if he wanted to reformat C: after a particularly bad example of UB.

Is it possible to read
from a file which already closed at least once out of 1000 times on
thousand different environment?

I suspect most platforms will not ley you write to a closed file. Why
would you
want to do this? You might survive sticking your fingers in a live
electrical socket,
but why do that?

 

[Ingo Menger]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?

No, it means, it will actually work as expected in most cases. When
using an uninitialized pointer, I expect a segmentation fault. However,
the variable fp could by chance have the same value as stdin, so that
once in some million years it would read something from stdin. This,
however, would be totally unexpected behaviour.

 

[Richard Bos]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?

Sure, if you want to risk your neck, feel free. If you want to risk it
working fine on your testing machine, but corrupting data on your users'
differently specced boxes, and your users are OK with that, go right
ahead. Make absolutely sure not to try such tricks on _my_ data, though.

Richard

 

[Christopher Benson-Manica]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];
fopen("file.txt","w+");

Until you replace this with what you presumably meant, namely

fp=fopen("file.txt","w+");

, the probability of this program working "as expected" is effectively
zero.

fprintf(fp,"HI\n");
fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?Is it possible to read
from a file which already closed at least once out of 1000 times on
thousand different environment?

Sure, it MIGHT work. Why on earth would you want to take the chance?
Programmers don't deal in "maybe", and neither do customers.

 

[Martin Ambuhl]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

This is useless. The result of the fopen() call needs to be assigned to
a FILE *. In your case
fp = fopen("file.txt", "w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);

And if fp had been fopened once, it isn't anymore. Dead again.

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

I know this will invoke undefined behaviour.

Since you never connect fp to a stream, the three statements after the
fopen() all try to use an uninitialized pointer.

Does undefined behavior
mean it MIGHT also work as expected in this case?

Ain't no chance in hell your code will work, unless whatever way your
implementation handles fprintf(), fclose(), and fscanf() calls using an
uninitialized pointer-to-FILE is your expectation.

Is it possible to read
from a file which already closed at least once out of 1000 times on
thousand different environment?

Just open the damn thing.

 

[Martin Ambuhl]

(e-mail address removed) schrieb:

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?

No, it means, it will actually work as expected in most cases.

His code, of course, will *never* work. "Never work" and "will actually
work as expected in most cases" are not synonyms.

 

[Jordan Abel]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

I'll assume you meant fp = fopen(...);

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);

after fclose(), the value of its argument becomes indeterminate.

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

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?Is it possible to read
from a file which already closed at least once out of 1000 times on
thousand different environment?

undefined behavior can mean anything. on most systems, it probably
doesn't mean you get to read from the file. even if it doesn't free()
the underlying file pointer, it'll probably still close the file [say,
posix close()]

 

[Keith Thompson]

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?Is it possible to read
from a file which already closed at least once out of 1000 times on
thousand different environment?

If your program invokes undefined behavior, it's always possible that
it will behave as you expect, whatever your expectations happen to be.
(That's not quite true; if you expect it to do something physically or
logically impossible, that's not going to happen -- but as far as the
standard is concerned, anything is possible.)

In this particular case, assuming you assign the result of fopen() to
fp, if the program displays "HI", it *probably* indicates that the
implementation is broken (e.g., fclose() doesn't work properly). If
the breakage only shows up for programs that invoke undefined
behavior, the implementation could still be conforming.

More realistically, consider something like this:

fp1 = fopen("some_file", "r");
...
fclose(fp1);
fp2 = fopen("another_file", "r");
fscanf(fp1, "%s", s);

Since fp1 is closed before fp2 is opened, it's plausible that fopen()
could return the same pointer value for both. In this case, reading
from fp1, even though it's closed, would most likely read from
"another_file". (I've just demonstrated this in a small program.)

As I'm sure you know, the lesson is: Don't do this.

 

[Markus Moll]

Hi

If your program invokes undefined behavior, it's always possible that
it will behave as you expect, whatever your expectations happen to be.
(That's not quite true; if you expect it to do something physically or
logically impossible, that's not going to happen -- but as far as the
standard is concerned, anything is possible.)

Who says so?
I'll build a computer that sets fire to the programmer's house every time he
or she invokes undefined behavior!
On second thought, maybe not _every_ time. That would be too well
defined ;-)

SCNR
Markus

 

[Keith Thompson]

Who says so?

The standard says so. C99 3.4.3 is the definition of the term
"undefined behavior:

undefined behavior

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on
integer overflow.

(Presumably "integer overflow" refers to *signed* integer overflow;
unsigned integer overflow is well defined.)

I'll build a computer that sets fire to the programmer's house every
time he or she invokes undefined behavior!

Such an implementation would not violate the C standard. It would
undoubtedly violate a lot of other things.

On second thought, maybe not _every_ time. That would be too well
defined ;-)

Undefined behavior is not required to be either consistent or
inconsistent.

 

[Michael Mair]

EXAMPLE An example of undefined behavior is the behavior on
integer overflow.

(Presumably "integer overflow" refers to *signed* integer overflow;
unsigned integer overflow is well defined.)

Hmmm, Question:
unsigned long example = (double)((unsigned long) -1) + 2;
is not guaranteed to yield example = 1 (e.g. C89 3.2.1.3 or
C99 6.3.1.4).
Is this a question of unsigned integer overflow or just a
"conversion problem"?

Cheers
Michael

 

[slebetman]

Hmmm, Question:
unsigned long example = (double)((unsigned long) -1) + 2;
is not guaranteed to yield example = 1 (e.g. C89 3.2.1.3 or
C99 6.3.1.4).
Is this a question of unsigned integer overflow or just a
"conversion problem"?

Integer overflow, in C unsigned int overflows are defined to roll over
to zero and back to 1, signed int overflow are not defined.

Example, for a 32bit platform:

unsigned int i = 0xffffffff;
int n = 0x7fffffff;

i += 2; /* is defined as 1 */
n += 2; /* may be -2147483647, may be -1, may be 1, may be anything
* the C standard says this is UB, it is up to the
implementation.
* On MY compiler, it is documented to generate -2147483647.
* The standard doesn't require this to be documented.
*/

 

[pete]

Hmmm, Question:
unsigned long example = (double)((unsigned long) -1) + 2;
is not guaranteed to yield example = 1 (e.g. C89 3.2.1.3 or
C99 6.3.1.4).
Is this a question of unsigned integer overflow or just a
"conversion problem"?

That's a conversion problem.
"Overflow" is used to decribe what happens
as the result of mathematic operations.

 

[pete]

Integer overflow, in C unsigned int overflows are defined to roll over
to zero and back to 1, signed int overflow are not defined.

No.
The assignment of an out of range floating type value
to an integer type,
is different from assigning an out of range integer value
to an int.

 

[Michael Mair]

That's a conversion problem.
"Overflow" is used to decribe what happens
as the result of mathematic operations.

Thanks for the clarification

 

[Michael Mair]

Integer overflow, in C unsigned int overflows are defined to roll over
to zero and back to 1, signed int overflow are not defined.

Example, for a 32bit platform:

unsigned int i = 0xffffffff;
int n = 0x7fffffff;

i += 2; /* is defined as 1 */
n += 2; /* may be -2147483647, may be -1, may be 1, may be anything
* the C standard says this is UB, it is up to the
implementation.
* On MY compiler, it is documented to generate -2147483647.
* The standard doesn't require this to be documented.
*/

This has nothing whatsoever to do with my question:
,- C99, 6.3.1.4 #1 ---
| When a finite value of real floating type is converted
| to an integer type other than _Bool, the fractional part
| is discarded (i.e., the value is truncated toward zero).
| If the value of the integral part cannot be represented
| by the integer type, the behavior is undefined.50)
`----

Cheers
Michael

 

[Zoran Cutura]

(e-mail address removed) schrieb:

#include <stdio.h>

int main()
{
FILE *fp;
char s[100];

fopen("file.txt","w+");

fprintf(fp,"HI\n");

fclose(fp);
fscanf(fp,"%s",s);
printf("%s\n",s);
}

I know this will invoke undefined behaviour.Does undefined behavior
mean it MIGHT also work as expected in this case?

No, it means, it will actually work as expected in most cases.

His code, of course, will *never* work. "Never work" and "will actually
work as expected in most cases" are not synonyms.

That mostly depends on what actually is expected!!

fp might for some strange reason be set to the return value of fopen
which would probably make it run as expected, OTOH this might never
happen. As to the UB in the OP was concerned about, there is no
guarantee that it will work at any time.