By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,889 Members | 1,297 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,889 IT Pros & Developers. It's quick & easy.

Dumb Question.

P: n/a
#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?

Dec 16 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
va******@rediffmail.com 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

Dec 16 '05 #2

P: n/a

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.

Dec 16 '05 #3

P: n/a
va******@rediffmail.com 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
Dec 16 '05 #4

P: n/a
va******@rediffmail.com 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.
Dec 16 '05 #5

P: n/a
va******@rediffmail.com 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.
Dec 16 '05 #6

P: n/a
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.

Dec 16 '05 #7

P: n/a
On 2005-12-16, va******@rediffmail.com <va******@rediffmail.com> 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()]
Dec 16 '05 #8

P: n/a
va******@rediffmail.com 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) ks***@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.
Dec 16 '05 #9

P: n/a
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

Dec 16 '05 #10

P: n/a
Markus Moll <mo**@rbg.informatik.tu-darmstadt.de> writes:
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?


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.

--
Keith Thompson (The_Other_Keith) ks***@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.
Dec 17 '05 #11

P: n/a
Keith Thompson wrote:
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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Dec 17 '05 #12

P: n/a
Michael Mair wrote:
Keith Thompson wrote:
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"?


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

Dec 17 '05 #13

P: n/a
Michael Mair wrote:

Keith Thompson wrote:
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"?


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

--
pete
Dec 17 '05 #14

P: n/a
sl*******@yahoo.com wrote:

Michael Mair wrote:
Keith Thompson wrote:
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"?


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.

--
pete
Dec 17 '05 #15

P: n/a
pete wrote:
Michael Mair wrote:
Keith Thompson wrote:
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"?


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


Thanks for the clarification

--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Dec 17 '05 #16

P: n/a
sl*******@yahoo.com wrote:
Michael Mair wrote:
Keith Thompson wrote:
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"?


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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Dec 17 '05 #17

P: n/a
Martin Ambuhl <ma*****@earthlink.net> wrote:
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.


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.

--
Z (zo**********@web.de)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Dec 19 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.