info about EOF

[osmium]

Personally, I don't see a problem in knowing the value of EOF. But
unless you're implementing your own fgetc() for a particular platform,
the knowledge is next to useless.

I think that illustrates the fundamental problem. A huge majority of people
think that information should be useful. If I were to categorize all the
things I knew, there is not a doubt in my mind that the vast majority of
what I know is useless to me. and quite likely to anyone else as well.

What I know:

1. Most crows are black.
2. and so forth

 

[osmium]

That depends on how obstinate and argumentative the listener chooses to
be. To a reasonable listener, "the precise value of EOF is irrelevant"
is quite sufficient. Seven words instead of five - so sue me.

So if I may summarize:
You don't need to know because it is irrelevant.
For a suitable definition of "because"

I think I am tired of this game.

 

[James Kuyper]

Tom St Denis wrote: ....

Keep it mind that "the exact value of EOF" varies, so "an exact value of
EOF" would be better wording.

But more fundamental, how does it *hurt* to know what it is?

The main problem with knowing what it is, is that you might be tempted
to make use of that knowledge. There's no good way to make use of that
knowledge, and a lot of bad ways. It's arguably better to not know, and
therefore remove any possibility of being tempted to use the knowledge,
however minor that temptation might be.

This implies, correctly, that if you have justifiable certainty in your
ability to avoid the temptation, then there is no danger, and therefore
no reason not to learn it. In the unlikely event that I ever had the
slightest interest knowing that value, I'd feel no compunction about
learning it - I know I can resist such a trivial temptation.

In a similar vein, I doubt if it helps to know pi to more than 20 places.
But many people know how to find or even compute this value. ...

That knowledge is useful: it provides a back up, in the event that an
already-tabulated value is unavailable. In addition, knowing how to find
this value gives you the conceptual basis for calculating the value of
other important numbers, many of which have an importance of such
limited scope that no one have ever tabulated their values yet. If you
need the value of such a number, knowing how to calculate pi gives you
the mental tools needed to calculate some of those other numbers as well.

 

[James Kuyper]

On 03/22/2011 03:09 PM, osmium wrote:
....

"EOF is often -1" has five words in it. Case closed. As a side effect it
explains, it an elliptical way, why some functions return an int rather than
a char.

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

The explanation conveys information that is, literally, infinitely more
valuable than knowing that "EOF is often -1"; it's entirely appropriate
to spend more words on the explanation.

However, in principle, "EOF is often -1" already contains the key part
of the explanation: any sufficiently wise programmer would look at the
word "often", realize that it isn't "always", and take the appropriate
actions. The problem is that many programmers lack the wisdom needed to
respond in that fashion; they'll make the mistake of paying attention to
the rest of the sentence, as if it contained useful information, and
make the further mistake of actually using that information.

 

[Malcolm McLean]

The problem is that many programmers lack the wisdom needed to
respond in that fashion; they'll make the mistake of paying attention to
the rest of the sentence, as if it contained useful information, and
make the further mistake of actually using that information.

Which is the same argument the Church used.

If people who were so poorly educated they couldn't even speak Latin
started reading the Bible, you could get all sorts of strange
interpretations being offered. So the information was hidden.

 

[Mark Bluemel]

Which is the same argument the Church used.

If people who were so poorly educated they couldn't even speak Latin
started reading the Bible, you could get all sorts of strange
interpretations being offered. So the information was hidden.

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

 

[James Kuyper]

Which is the same argument the Church used.

If people who were so poorly educated they couldn't even speak Latin
started reading the Bible, you could get all sorts of strange
interpretations being offered. So the information was hidden.

I'm arguing that the information, which I recommend not bothering to
learn, is useless. I'm not suggesting that it be made unavailable, just
that there's no point in taking advantage of it's availability.

They argued that the information they wanted to be hidden, was so
extremely important that it's interpretation must not be allowed in the
hands of people lacking adequate credentials.

I see those differences as being sufficiently important to render
inapplicable any negative connotations you may be implying by making the
comparison.

 

[James Kuyper]

On 03/23/2011 05:38 AM, Mark Bluemel wrote:
....

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

That sounds like a joke, but just in case that was a serious question,
the answer is:

Yes, you can duplicate it. However: "The address of the FILE object used
to control a stream may be significant; a copy of a FILE object need not
serve in place of the original." (7.19.3p6), so making use of the
duplicate is problematic, at best, and certainly not portable.

 

[Uno]

What's an "EOF character" ?

I don't know. I suspect that you do, that is, you can disambiguate
'EOF' in terms of the C programming language effectively.

There must have been a dozen references to EOF in Plauger's glossary.

Wouldn't it have to be a macro?

 

[Tom St Denis]

So if I may summarize:
    You don't need to know because it is irrelevant.
 For a suitable definition of "because"

I think I am tired of this game.

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

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

Tom

 

[Keith Thompson]

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

Agreed, mostly.

On the other hand, each of the is*() functions in <ctype.h> is
required to accept an argument with the value EOF as well as any
value in the range 0 .. UCHAR_MAX. Some implementations assign EOF
the value -1 so that the values can be represented in a contiguous
array.

This isn't particularly useful information, but it is interesting.

 

[Malcolm McLean]

Agreed, mostly.

On the other hand, each of the is*() functions in <ctype.h> is
required to accept an argument with the value EOF as well as any
value in the range 0 .. UCHAR_MAX.  Some implementations assign EOF
the value -1 so that the values can be represented in a contiguous
array.

This isn't particularly useful information, but it is interesting.

And it tempts someone to write

/* does a letter have curly lines? */
int iscurly(int ch)
{
return mycurlyarray[ch + 1];
}

which will pass every black box test on every platform you have
available, but might go horribly wrong somewhere.

 

[Ceriousmall]

C Programming Language Second Edition.....................
Page 17 Exercise 1-6 Verify that the expression getchar() != EOF is 0
or 1
Exercise 1-7 Write a program to print the value of EOF

The Gods gave us permission to know guys...............

 

[Kenny McCormack]

There are no gods, and this conversation is about the *usefulness* of
knowing the value of EOF, not whether we're "allowed" to know it.

No, we're not. First of all, "usefulness" is always a man-of-straw and a
proxy for religious people wanting to keep the masses uninformed. It goes
all the way back to God trying to convince Adam & Eve that it wasn't
"useful" to eat of the Tree. Hint: The serpent was right.

For one thing, "usefulness" is "in the eye of the beholder". No one can
tell someone else whether or not something is useful to that other person.
CLC has a very narrow view of usefulness, just as it has a very narrow view
of, well, everything. If knowing the value of EOF (on a certain platform)
can get me a date with a hot (but geeky) chick, then, I think we can all
agree that such knowledge is quite useful indeed.

For another, if you guys were being honest, and really didn't think it was
useful to know the value of EOF, you should be *wanting* us guys to know it
and to spend (i.e., waste) time and effort attaining that knowledge, because
that would improve your competitive edge. That you seem so upset and worried
that we might attain the knowledge (just as God was upset & worried about,
well, you know...) belies the credibility of your position.

 

[Malcolm McLean]

No, we're not.  First of all, "usefulness" is always a man-of-straw anda
proxy for religious people wanting to keep the masses uninformed.

Real polices are often kept from the masses, for a variety of reasons,
not all of them bad.

 

[Chris H]

Do you actually believe all that babble?

I was thinking that.

Just wondering, 'cause I have a score file, and I ain't afraid to use it.

Good Idea... however like QI I think you should award negative points as
well as positive points. I suspect even the "winner" would have a large
negative score ))


BTW There is a lot of difference between data and information and
knowledge. Not all data imparts knowledge.

EOF is well EOF like NULL is NULL, yes both have a value but it can and
does sometimes change. Knowing the value is rarely any help.

Knowing the value of EOF or NULL is usually at best no use or at worst
counter productive. Whilst there are some exceptions they are just
that... exceptions and not a good reason for general use.

Personally I can come up with several examples of when it is useful to
have a gun about one's person. One of which actually happened to me in
the UK (several decades ago). However it is not a good reason for
letting the public have guns. In the same way that some people use LSD
on prescription it does not validate all LSD users.

 

[Kenny McCormack]

Do you actually believe all that babble?

Just wondering, 'cause I have a score file, and I ain't afraid to use it.

Somehow, I just don't see us going to the prom together...

 

[Chris H]

Somehow, I just don't see us going to the prom together...

Well may be for the Last Night.

 

[Dr Nick]

Do you actually believe all that babble?

Just wondering, 'cause I have a score file, and I ain't afraid to use it.

He escaped from mine a couple of days ago. I've been watching in
horrified fascination - I'd forgotten the ghastliness of the reality.

 

[Seebs]

But more fundamental, how does it *hurt* to know what it is?

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.

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.

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.

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

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.

-s