Dumb Question.

[vashwath@rediffmail.com]

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

Re: Dumb Question.

vashwath@rediff mail.com wrote:
[color=blue]
> #include <stdio.h>
>
> int main()
> {
> FILE *fp;
> char s[100];
>
> fopen("file.txt ","w+");[/color]

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...
[color=blue]
> 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?[/color]

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.
[color=blue]
> Is it possible to read
> from a file which already closed at least once out of 1000 times on
> thousand different environment?[/color]

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

[Ingo Menger]

Re: Dumb Question.


vashw...@rediff mail.com schrieb:
[color=blue]
> #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?[/color]

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]

Re: Dumb Question.

vashwath@rediff mail.com wrote:
[color=blue]
> #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?[/color]

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]

Re: Dumb Question.

vashwath@rediff mail.com wrote:
[color=blue]
> #include <stdio.h>[/color]
[color=blue]
> int main()
> {
> FILE *fp;
> char s[100];
> fopen("file.txt ","w+");[/color]

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.
[color=blue]
> fprintf(fp,"HI\ n");
> fclose(fp);
> fscanf(fp,"%s", s);
> printf("%s\n",s );
> }[/color]
[color=blue]
> 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?[/color]

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)cybers pace.org | don't, I need to know. Flames welcome.

[Martin Ambuhl]

Re: Dumb Question.

vashwath@rediff mail.com wrote:[color=blue]
> #include <stdio.h>
>
> int main()
> {
> FILE *fp;
> char s[100];
>
> fopen("file.txt ","w+");[/color]

This is useless. The result of the fopen() call needs to be assigned to
a FILE *. In your case
fp = fopen("file.txt ", "w+");[color=blue]
>
> fprintf(fp,"HI\ n");
>
> fclose(fp);
> fscanf(fp,"%s", s);[/color]

And if fp had been fopened once, it isn't anymore. Dead again.
[color=blue]
> printf("%s\n",s );
> }
>
> I know this will invoke undefined behaviour.[/color]

Since you never connect fp to a stream, the three statements after the
fopen() all try to use an uninitialized pointer.
[color=blue]
> Does undefined behavior
> mean it MIGHT also work as expected in this case?[/color]

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.
[color=blue]
> Is it possible to read
> from a file which already closed at least once out of 1000 times on
> thousand different environment?[/color]

Just open the damn thing.

[Martin Ambuhl]

Re: Dumb Question.

Ingo Menger wrote:[color=blue]
> vashw...@rediff mail.com schrieb:
>
>[color=green]
>>#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?[/color]
>
>
> No, it means, it will actually work as expected in most cases.[/color]

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

[Jordan Abel]

Re: Dumb Question.

On 2005-12-16, vashwath@rediff mail.com <vashwath@redif fmail.com> wrote:[color=blue]
> #include <stdio.h>
>
> int main()
> {
> FILE *fp;
> char s[100];
>
> fopen("file.txt ","w+");[/color]

I'll assume you meant fp = fopen(...);
[color=blue]
> fprintf(fp,"HI\ n");
>
> fclose(fp);
> fscanf(fp,"%s", s);[/color]

after fclose(), the value of its argument becomes indeterminate.
[color=blue]
> 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?[/color]

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]

Re: Dumb Question.

vashwath@rediff mail.com writes:[color=blue]
> #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?[/color]

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_fil e", "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_fi le". (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_Keit h) kst-u@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.

[Markus Moll]

Re: Dumb Question.

Hi

Keith Thompson wrote:
[color=blue]
> 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.)[/color]

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]

Re: Dumb Question.

Markus Moll <moll@rbg.infor matik.tu-darmstadt.de> writes:[color=blue]
> Keith Thompson wrote:
>[color=green]
>> 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.)[/color]
>
> Who says so?[/color]

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.)
[color=blue]
> I'll build a computer that sets fire to the programmer's house every
> time he or she invokes undefined behavior! :-)[/color]

Such an implementation would not violate the C standard. It would
undoubtedly violate a lot of other things.
[color=blue]
> On second thought, maybe not _every_ time. That would be too well
> defined ;-)[/color]

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

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Michael Mair]

Re: Dumb Question.

Keith Thompson wrote:[color=blue]
> 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.)[/color]

Hmmm, Question:
unsigned long example = (double)((unsig ned 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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[slebetman@yahoo.com]

Re: Dumb Question.

Michael Mair wrote:[color=blue]
> Keith Thompson wrote:[color=green]
> > 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.)[/color]
>
> Hmmm, Question:
> unsigned long example = (double)((unsig ned 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"?
>[/color]

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]

Re: Dumb Question.

Michael Mair wrote:[color=blue]
>
> Keith Thompson wrote:[color=green]
> > 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.)[/color]
>
> Hmmm, Question:
> unsigned long example = (double)((unsig ned 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"?[/color]

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

--
pete

[pete]

Re: Dumb Question.

slebetman@yahoo .com wrote:[color=blue]
>
> Michael Mair wrote:[color=green]
> > Keith Thompson wrote:[color=darkred]
> > > 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.)[/color]
> >
> > Hmmm, Question:
> > unsigned long example = (double)((unsig ned 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"?
> >[/color]
>
> Integer overflow, in C unsigned int overflows are defined to roll over
> to zero and back to 1, signed int overflow are not defined.[/color]

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.

--
pete