info about EOF

[Seebs]

"EOF is often -1" has five words in it. Case closed.

What case does that make?

I'd have just said "EOF is negative".

As a side effect it
explains, it an elliptical way, why some functions return an int rather than
a char.

Not really, because to understand that, you have to know that they're
otherwise returning a value coerced to unsigned char's range...

How many word are in the explanation about *why* it is poor practice?

I would rather have a long explanation that results in a good understanding
than a short explanation that results in a bad understanding, for the most
part.

-s

 

[Seebs]

You never answered why you need to know it's value. That's what
puzzles me. It's like having to know the value of any one of the many
constants behind the scene. Do you know the syscall number for
open()? Or write()? No. Why? It's not fucking important [unless
you're writing a C library from scratch...].

Heck, you may not even need to know it then. I've dug around in that code
more than anyone should ever have cause to, and I've needed to know something
about syscall numbers roughly once in the last fifteen years; I was trying
to figure out why some sytems had multiple syscalls for some socket
operations and some had a single overloaded number that took more arguments.

I ended up spending about three hours studying the MIPS ABI and Linux
kernel implementation in order to give a tech review of a two-line change
which was "obviously correct".

(Answer: Yes, it was correct. But now I could explain WHY it was correct.)

Knowing the value of EOF is useless. It's EOF. Done.

Exactly.

-s

 

[Seebs]

Do you actually believe all that babble?

He does. It is simply alien to his world that anyone could have goals
other than improvement of relative status. We can state with confidence
that one of two things is true:

1. He genuinely does not believe that anyone has any other motivation.
2. He feels that he will gain personal advantage by claiming that he
does not believe that anyone has any other motivation.

It's really hard to tell which; obviously, he'd lie if he thought it would
make him look good. What's weird is trying to figure out how he could
possibly think any of this makes him look good.

-s

 

[Seebs]

Can we move on to an exploration of what "FILE" means in C? Can I use
memcpy to duplicate an open file?

You can! However, there is no guarantee that a pointer to the duplicate
will be functionally usable as a replacement for a pointer to the original.

-s

 

[Ben Bacarisse]

Humans are very bad at distinguishing between "things that I know happened
to be true once" and "things that I know to be true by definition" when they
are thinking about something else.

I have to take your word for that, but I am not aware of having trouble
with that distinction myself.

How would it hurt you to know the exact non-zero value your FORTRAN compiler
produces for .TRUE. when working with C?

#define IS_TRUE(x) ((x) == 0x100)

This actual code occurred in a large code base. They upgraded their FORTRAN
compiler and suddenly the C++ that interacted with it blew up, misidentifying
true things as false. I happened to look at the code and saw:

do_the_real_work(foo, bar, IS_TRUE(baz));

and told them "take out the IS_TRUE, it'll work". I later got to see the
definition

The trouble with this anecdote is that you don't know what the author of
the code knew. They may have had access nothing but the value of
..TRUE. on one system at one time. They may not have been privy to what
..TRUE. *has* to be rather than what it *happens* to be. I.e. this is
probably an anecdote about knowing to little, not about knowing too much.

Basically, someone who knows that EOF is "-1" rather than "some unspecified
negative value" is like to also know that things are twos complement and end
up writing something that does:

x = x & c;

because they *know* that, if c is EOF, it'll be a no-op.

Maybe, but is anyone here arguing for giving people *only* that
information? I though the debate was about knowing some actual value of
EOF in addition to the more general information about it.

Someone who doesn't know what EOF is will say "what happens if you and
something with EOF, which isn't a meaningful value?"

Yes, this is a case where ignorance can prevent a mistake, but you've
not described a situation where having all the information (even those
bits that are transient or highly specific) is a danger.

True story: I do not know what value EOF has on the systems I use
regularly. No clue. I mean, obviously it's negative. No clue past that.
I've never looked, I've never written code that cared, heck, I don't think
I've even used any test other than ==/!= EOF on a value that I suspected of
being EOF.

And if you did find out what it is, would that lead you to make the kind
of errors you've described? Do you fear that someone will tell you what
EOF is at the water cooler and you'll start to make these errors? No, I
am sure you could handle that information in your stride, just as I am
not at all worried by the fact that I happen to what EOF is on this
system.

If all you are saying is that there is no need to now, I suspect we all
agree on that, but I feel you are suggesting something else but I am not
sure I know what it is.

 

[J. J. Farrell]

Well may be for the Last Night.

Oh, very nice! Wit has not yet been driven from c.l.c.

 

[osmium]

I have to take your word for that, but I am not aware of having trouble
with that distinction myself.


The trouble with this anecdote is that you don't know what the author of
the code knew. They may have had access nothing but the value of
.TRUE. on one system at one time. They may not have been privy to what
.TRUE. *has* to be rather than what it *happens* to be. I.e. this is
probably an anecdote about knowing to little, not about knowing too much.


Maybe, but is anyone here arguing for giving people *only* that
information? I though the debate was about knowing some actual value of
EOF in addition to the more general information about it.


Yes, this is a case where ignorance can prevent a mistake, but you've
not described a situation where having all the information (even those
bits that are transient or highly specific) is a danger.


And if you did find out what it is, would that lead you to make the kind
of errors you've described? Do you fear that someone will tell you what
EOF is at the water cooler and you'll start to make these errors? No, I
am sure you could handle that information in your stride, just as I am
not at all worried by the fact that I happen to what EOF is on this
system.

If all you are saying is that there is no need to now, I suspect we all
agree on that, but I feel you are suggesting something else but I am not
sure I know what it is.

As far as I can tell, the message is "Father knows best". Simply
paternalism run amok.

 

[Seebs]

I have to take your word for that, but I am not aware of having trouble
with that distinction myself.

Experienced programmers tend to be better about it. The main problem isn't
in the conscious awareness, though, it's in the tendency for the brain to
fill in answers that are partial results to something else.

Same general principle as a whole lot of social engineering attacks and
tricks. If you accuse someone of something they would like to deny, they are
likely to deny it. If you state something that necessarily implies that
thing, they may not notice that the implication is one they're trying to
deny.

So, someone who would easily spot something direct like "were you at the
nightclub at the time of the murder" might easily fall for "did you see anyone
you knew at the nightclub at the time of the murder?"

Similarly, even if you *know* that EOF may have values other than -1, if
you've seen it as -1 and know it's -1 on a given implementation, you're
less likely to wonder whether something like:

/* we take a pointer to [1] so we can index by -1 */
int flagtable[] = {
0xff, /* EOF */
0x00, /* NUL */
}, *flags = flagtable + 1;

is safe. You know how it works.

The trouble with this anecdote is that you don't know what the author of
the code knew. They may have had access nothing but the value of
.TRUE. on one system at one time. They may not have been privy to what
.TRUE. *has* to be rather than what it *happens* to be. I.e. this is
probably an anecdote about knowing to little, not about knowing too much.

Well, that's the thing. If you asked the vendor, they told you that .FALSE.
was all bits zero, and .TRUE. wasn't.

Maybe, but is anyone here arguing for giving people *only* that
information? I though the debate was about knowing some actual value of
EOF in addition to the more general information about it.

See above; people tend to generalize a little bit unconsciously even when
they know better.

And if you did find out what it is, would that lead you to make the kind
of errors you've described?

I'd be more likely to than I am now.

If all you are saying is that there is no need to now, I suspect we all
agree on that, but I feel you are suggesting something else but I am not
sure I know what it is.

I come to programming from an unusual background, which is that I studied
psychology. I've spent a lot of my time totally fascinated by the ways in
which human brains are unreliable. This is of particular interest because
my brain is very, very, heavily optimized for speed over reliability; I'm
extremely fast, but I have a particularly noticeable tendency towards a lot
of the common cognitive errors. (Mostly not the socially-focused ones,
though.)

Human brains are... Well, frankly, they're *astoundingly* bad. Classic
example: You have a bunch of people on a subway car. A woman announces
that her radio has been stolen. The majority of the people present are
able to give a description of the person who took the radio.

There *wasn't* a radio. No radio was ever present. But they remember seeing
it taken.

In general, if you have information which is *nearly* the piece of information
you need, and the piece of information you need is unknown or even known to
be unknowable (such as "the" value of EOF for purposes of a portable program),
your brain is extremely likely to fill in something Useful.

Good programmers (and engineers, and mathematicians, and lawyers, and just
about everyone else who has to think for a living) are much better than
resisting this than people who haven't trained for it, but they are still
vulnerable to it.

-s

 

[Seebs]

As far as I can tell, the message is "Father knows best". Simply
paternalism run amok.

Nothing of the sort.

-s

 

[Ben Bacarisse]

On 2011-03-25, Ben Bacarisse <[email protected]> wrote:

Well, that's the thing. If you asked the vendor, they told you that .FALSE.
was all bits zero, and .TRUE. wasn't.

I am still a little puzzled. Are you saying the code author did know
this (in which case you left out the key fact from the anecdote -- the
fact that makes it apply to this case) or are you agreeing with me that
it is story about having too little rather than to much information?

See above; people tend to generalize a little bit unconsciously even when
they know better.

I could not find anything above that was about people generalising when
they know better. Are you referring to the anecdote about .TRUE.?

I'd be more likely to than I am now.

"More likely" includes probabilities that are as small one wants to have
them, so this seems to be almost deliberately evasive!

I come to programming from an unusual background, which is that I studied
psychology. I've spent a lot of my time totally fascinated by the ways in
which human brains are unreliable. This is of particular interest because
my brain is very, very, heavily optimized for speed over reliability; I'm
extremely fast, but I have a particularly noticeable tendency towards a lot
of the common cognitive errors. (Mostly not the socially-focused ones,
though.)

Human brains are... Well, frankly, they're *astoundingly* bad. Classic
example: You have a bunch of people on a subway car. A woman announces
that her radio has been stolen. The majority of the people present are
able to give a description of the person who took the radio.

There *wasn't* a radio. No radio was ever present. But they remember seeing
it taken.

I am not unaware of these phenomena. The trouble I have is that I don't
find your descriptions of them easy to relate to the case being
discussed. There are lots of experiments that show that people will
construct false accounts of events when prompted to do so (and sometimes
with no prompting at all). Are you sure that they carry over in a
specific rather than a general way to the case being discussed? By
which I mean that there is not much to be learnt from the fact the
brains are bad at stuff so all kinds of mistakes are possible -- there
must be something much more specific that you believe applies here.

To take a step back, we are talking about someone learning C not someone
being asked to recall a stressful situation where incorrect information
has been thrown into the mix. We are not talking about hiding or in any
way obscuring the important general rule that nothing should be assumed
about EOF other than the fact that it is a negative int. Yet I think
you are saying that the arrival of some extra information about what it
is in once instance will start to poison this general knowledge to the
point where mistakes are so likely that the information should, in fact,
be withheld. You may be right, but I not at all sure that evidence from
witness experiments carries over to this case.

In general, if you have information which is *nearly* the piece of information
you need, and the piece of information you need is unknown or even known to
be unknowable (such as "the" value of EOF for purposes of a portable program),
your brain is extremely likely to fill in something Useful.

I can't relate that to this case. I thought we were talking about
people who have the information they need together with something extra
that they don't need. What people might fill in when they don't have
the information they need does not seem important.

<snip>

 

[ImpalerCore]

I have to take your word for that, but I am not aware of having trouble
with that distinction myself.

Experienced programmers tend to be better about it.  The main problem isn't
in the conscious awareness, though, it's in the tendency for the brain to
fill in answers that are partial results to something else.

Same general principle as a whole lot of social engineering attacks and
tricks.  If you accuse someone of something they would like to deny, they are
likely to deny it.  If you state something that necessarily implies that
thing, they may not notice that the implication is one they're trying to
deny.

So, someone who would easily spot something direct like "were you at the
nightclub at the time of the murder" might easily fall for "did you see anyone
you knew at the nightclub at the time of the murder?"

Similarly, even if you *know* that EOF may have values other than -1, if
you've seen it as -1 and know it's -1 on a given implementation, you're
less likely to wonder whether something like:

        /* we take a pointer to [1] so we can index by -1 */
        int flagtable[] = {
                0xff, /* EOF */
                0x00, /* NUL */
        }, *flags = flagtable + 1;

is safe.  You know how it works.

The trouble with this anecdote is that you don't know what the author of
the code knew.  They may have had access nothing but the value of
.TRUE. on one system at one time.  They may not have been privy to what
.TRUE. *has* to be rather than what it *happens* to be.  I.e. this is
probably an anecdote about knowing to little, not about knowing too much.

Well, that's the thing.  If you asked the vendor, they told you that .FALSE.
was all bits zero, and .TRUE. wasn't.  

Maybe, but is anyone here arguing for giving people *only* that
information?  I though the debate was about knowing some actual valueof
EOF in addition to the more general information about it.

See above; people tend to generalize a little bit unconsciously even when
they know better.

And if you did find out what it is, would that lead you to make the kind
of errors you've described?

I'd be more likely to than I am now.

If all you are saying is that there is no need to now, I suspect we all
agree on that, but I feel you are suggesting something else but I am not
sure I know what it is.

I come to programming from an unusual background, which is that I studied
psychology.  I've spent a lot of my time totally fascinated by the waysin
which human brains are unreliable.  This is of particular interest because
my brain is very, very, heavily optimized for speed over reliability; I'm
extremely fast, but I have a particularly noticeable tendency towards a lot
of the common cognitive errors.  (Mostly not the socially-focused ones,
though.)

Human brains are... Well, frankly, they're *astoundingly* bad.  Classic
example:  You have a bunch of people on a subway car.  A woman announces
that her radio has been stolen.  The majority of the people present are
able to give a description of the person who took the radio.

To say that brains are *astoundingly* bad is subjective; the only
reason something appears bad is in contrast to something else that is
good. Which implies that there exists something else in your mind
that you can compare them to that makes them look bad.

On the flip side, IBM spends millions of dollars on hardware and
software algorithms just to try to compete with a human's brain in
Jeopardy. Okay, Watson beat a couple skilled people because of
reaction time, let's ask them to try to fit that computer into the
physical confines of a human skull I would say that this makes the
technology of the brain look *astoundingly* good. The fact that
several brains controlling autonomous agents with a way to communicate
with each other to even create a computer like Watson implies that the
collective power of brains is also *astoundingly* good.

Best regards,
John D.

 

[Seebs]

I am still a little puzzled. Are you saying the code author did know
this (in which case you left out the key fact from the anecdote -- the
fact that makes it apply to this case) or are you agreeing with me that
it is story about having too little rather than to much information?

I don't know for sure. I know that it was a decision which came from
the belief that they knew what the value was; had they only believed that
they knew something about it, they couldn't have made that mistake.

I could not find anything above that was about people generalising when
they know better. Are you referring to the anecdote about .TRUE.?

That and everything else. Humans who have a concrete piece of information
will tend to apply it more generally than they should.

"More likely" includes probabilities that are as small one wants to have
them, so this seems to be almost deliberately evasive!

I'd guess it'd be in the "will happen at least once a year" range. Well,
depending; I don't write much code in which it would come up.

Are you sure that they carry over in a
specific rather than a general way to the case being discussed? By
which I mean that there is not much to be learnt from the fact the
brains are bad at stuff so all kinds of mistakes are possible -- there
must be something much more specific that you believe applies here.

Not totally sure, but strongly suspicious. It's possible that, once
people know that something isn't portable, they never get screwed up by it;
I haven't been able to prove that the people I see screwing up by relying
on a local quirk were definitely exposed to the more portable answer, or
definitely weren't. But I see a lot of code that makes those mistakes...

Yet I think
you are saying that the arrival of some extra information about what it
is in once instance will start to poison this general knowledge to the
point where mistakes are so likely that the information should, in fact,
be withheld.

Not necessarily. I'm just saying it will have *some* downside. It may be
that the downside is less than the benefit of having a clearer understanding
of how specific implementations choose to handle such requirements!

I can't relate that to this case. I thought we were talking about
people who have the information they need together with something extra
that they don't need. What people might fill in when they don't have
the information they need does not seem important.

I guess... The thing is, the anti-information you need to have about EOF
isn't really the same kind of claim. If you want the bit pattern, you
can't get it from "an unspecified negative value" but you might be able
to get it from "-1", so if you are for some reason looking at a bitwise
operation on EOF, your brain may pick the answer it can give rather than
the answer it can't.

These kinds of things would be hard to test for conclusively. My main
observation is just that I sure do see a lot of posts where people appear
to be assuming that something they learned about a specific system is general,
and I think at least some of them are from people who, in theory, know about
the general case.

-s

 

[James Kuyper]

: ....

As far as I can tell, the message is "Father knows best". Simply
paternalism run amok.

It is nothing of the kind. There is no appeal to parental authority
being made here. Anyone with adequate understanding of the relevant
issues can figure for themselves why knowing the value of EOF is
pointless in almost all circumstances, there's no need to accept the
authority of some privileged elite about the reason for this.

 

[Ben Bacarisse]

On 2011-03-25, Ben Bacarisse <[email protected]> wrote:

[You've sniped attributions, but this was you earlier:]

I'd guess it'd be in the "will happen at least once a year" range.

I can't ague with that. If someone with your skills and experience
feels that knowing what EOF happens to be will cause you to write code
that assumes that value "about once a year" then I must agree that the
knowledge is dangerous.

<snip>

 

[Seebs]

I can't ague with that. If someone with your skills and experience
feels that knowing what EOF happens to be will cause you to write code
that assumes that value "about once a year" then I must agree that the
knowledge is dangerous.

Not necessarily write the code; possibly miss that code I'm debugging
relies on it, for instance. The more the reliance is tangential to what
I'm doing, the more likely it is that I'll make the mistake. I'm a very
careful thinker, but only about the parts of the thinking that I'm doing
on purpose.

-s

 

[Kenny McCormack]

the information in this machine EOF is -1 is useful when someone
use a debugger in this machine.

Good example! But I think your posting illustrates well the fact
that CLC regs don't ever use debuggers or date girls [*].

[*] See my previous example of a situation where knowing the value of EOF
would be valuable.

--
One of the best lines I've heard lately:

Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)