«

#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?

wrote:

> #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?


--
Nick Keighley

vashw...@rediffmail.com 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. 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.

wrote:

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

wrote:

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

wrote:
> #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.

Ingo Menger wrote:
> vashw...@rediffmail.com 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.

On 2005-12-16, <> wrote:
> #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()]

writes:
> #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.

--
Keith Thompson (The_Other_Keith) kst- <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.

Hi

Keith Thompson wrote:

> 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