W
websnarf
Keith said:No, gets() should not be assumed to always invoke undefined behavior,
because it *doesn't* always invoke undefined behavior.
How is "doesn't have to be UB" distinct from "always UB"? The
distinction in this case is outside of the
specification/programmer/language's control. But that's basically the
same situation for pretty much *ALL* UB.
Look, if I manage a pointer with char * type, and only store/read from
it with a cast to (int *) you are going to say that what I am doing is
poorly defined, even though its it *doesn't* always invoke undefined
behavior. Whatever -- the fact that it sometimes works just fine
doesn't help -- it can do bad things that can only be soundly fixed by
recoding it to behave in another way. gets() is in exactly the same
situation.
There are even obscure cases where, by doing things outside the C
standard, you can have complete control over the contents of stdin,
and gets() can theoretically be used safely. (I still wouldn't use it
myself, but it's theoretically possible.)
This is often true for most other kinds of UB in general as well. Why
are you so energized to protect gets() as distinct from them?
"At all costs"? Get a grip, will you?
I can't make the OP give up on computer programming. I can make James
Dow Allen give up on computer programming (and that wouldn't even
necessarily be a good thing). People use gets() and will continue to
do so. There is no natural way to make them stop. Yet its wrong on
its face -- and they must be stopped. What would you recommend? My
proposal is pretty compelling and sort of solves the problem. I admit
its a bit like getting rabies shots, but the alternative is to simply
not have the cure available.
For the Nth time, I agree that gets() should not be in the language
and nobody should use it, but making it more dangerous than it already
is is not the answer
Who is proposing to make it more dangerous? The source I gave should
be fairly safe.
The fact that you don't want it in the standard, and I don't want it in
the standard doesn't matter -- the standards committee continues to
endorse its presence and usage. So agreeing with me on this point is
like agreeing that rape is bad -- its of little consolation to the
victims.
[...] -- and what you're proposing cannot be done in a conforming implementation.
What are you talking about? So long as the UB is always there, it
satisfies the specification. In the presence of UB, it can do anything
it wants.
If you want to have a non-conforming C implementation that discourages
gets(), just reject any program that calls it. If you want to have a
*conforming* C implementation that discourages gets(), issue a warning
(as gcc does).
Its actually the linker which is issuing the warning. I.e., in order
to "conform" with C, the gcc people just go ahead and do the bad thing
in their compiler like everyone else does (*sigh*). The C
specification does not say what should be done in the linker, so they
make the bold step of crossing the line at the linker stage. This is
unfortunate, as *OTHER* languages may have a different specification
that puts implicit limits on buffer sizes or uses some other mechanism
which makes it possible for them to use gets() safely -- and thus these
other languages are forced to work around this warning. Its probably
not a big deal, since you can rewrite another gets easily, but you can
see the point that the gcc people have pushed back to a completely
different position in order to be both conforming and at least prod the
developers a *little* bit, and they are willing to take a slight
theoretical system wide hit for it.
[...] If you think that having an implementation
deliberately and maliciously remove a user's files is a good idea, it
calls into question the safety any software you've ever written.
First of all, in most systems and typical usages gets() already does
this. I.e., I am not adding anything that isn't already in there. My
suggested implementation merely makes it more predictable.
Mind you, I don't believe you really think so. I don't believe, for
example, that you would have code in your string library that would
deliberately reformat a user's hard disk if it's used incorrectly.
My string library doesn't contain any functions with these sorts of
problems (that I know of.) I am open to fixing the library whenever
anomolies of design or implementation are pointed out. My library goes
to great lengths to eliminate unpredictable UB.
This is a completely different situation from gets(). The ANSI C
committee has openly declared hostile intent towards the software
industry by putting their stamp of approval on this function. They
even go so far as to put deceptive language in the standard in an
attempt to demonstrate they've addressed the problem of potential bad
uses of gets().
But it would be consistent with the arguments you're making here.
Yeah, you can just go ahead and stop trying to "analyze my arguments"
any time you feel like. I haven't been impressed in the past, and I am
not likely to now or in the future.