# Thread: Seem unable to use EOF?

1. Originally Posted by failure67
Um, EOF is an int. So assuming an int is 32 bits, then wouldn't the percent chance of EOF showing up by default be (2^-32)(100)? This, of course, isn't taking into account how often programs store or use the value EOF.
No, because not every value is equally likely. By far the most likely value in any given memory location is zero, probably somewhere on the order of 30%. Go on, pause a running program and look through its memory in the debugger.
The next most likely value is probably 1. -1 will be quite high up on the list also.

Why do you think a bug that it due to an uninitialised pointer often goes unnoticed for so long. Its because the value randomly happened to be NULL and thus terminated the linked list, or the program knew to allocate memory for it rather than trying to just use whatever it pointed to, or ...

2. No, because not every value is equally likely. By far the most likely value in any given memory location is zero, probably somewhere on the order of 30%. Go on, pause a running program and look through its memory in the debugger.
The next most likely value is probably 1. -1 will be quite high up on the list also.
My final sentence qualifies that.

My confusion comes from trying to figure out where he got the 256 and 50/50 numbers from. For the 256, the only ways I could think of somebody coming up with that are:

1) He's working on a system where ints are 8-bit
2) He's on a system where EOF does not conform to C standards (ie. EOF is returned as a char instead)
3) He made a simple careless mistake
4) He's quoting some research on the distribution of memory values that I've never heard about (Note: I've never read about any, so this is certainly possible)
5) (Unlikely) He's making numbers up

As for running it twice, that would be two Bernoulli trials (either the value is EOF or it's not). So I'm not sure where he got the 50/50 either.

Why do you think a bug that it due to an uninitialised pointer often goes unnoticed for so long. Its because the value randomly happened to be NULL and thus terminated the linked list, or the program knew to allocate memory for it rather than trying to just use whatever it pointed to, or ...
Please don't get me wrong. I'm all for removing a bug altogether rather than making it just unlikely.

3. A char occupies the lsb of an int... you may be receiving an int in return but you're treating it as a char... hence 1 in 256...
The 50/50 shot if you run the program twice in a row is about reusing the same memory... and the EOF left behind from the last use.

4. Originally Posted by CommonTater
A char occupies the lsb of an int... you may be receiving an int in return but you're treating it as a char... hence 1 in 256...
I think you are thinking too much (or perhaps you are thinking of a different program) since in the program posted in post #1, data is an int, not a char, and the first comparison with EOF was made before any C I/O function call.