Re: Why GCC does warn me when I using gets() function for accessing file

Philip Potter wrote:
<websnarf@xxxxxxxxx> wrote in message
Keith Thompson wrote:
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.

The standard says that integer overflow is UB; therefore, if I add 1 to an
int containing 32767, I may have invoked UB.

Correct, that's why Richard Seacord recently created a secure integer
library. (Personally, I just make sure my ranges make sense.)

[...] However, if I know that on my
system int is 17 bits or more, I can guarantee I haven't. The size of an int
is outside the programmer/language/specification's control, so according to
your argument this is still UB, and my implementation is free to reformat my
hard drive instead. I don't think many people would agree with you on this.

Uhhh ... that ANSI C committee itself agrees with this point of view.
I would actually prefer to take your point of view, and decribe a
limited scope of "bad behavior" for certain failures like numerical
overflows. But the ANSI C people decided not to bother with that. So
yes, overflowing an integer apparently can email the KGB the US nuclear
launch codes.

Similarly, if I know that on my system stdin gets a \n character at least
every 20 characters, I can use gets() and guarantee no UB.

All your doing is going ahead and translating the universe of UB that
comes with gets() into one narrow manifestation or predictable
behavior. That's exactly what I did in my sample implementation, BTW.
We can both do this, of course, because we are covered the by the UB.
Either way neither is behaving as the optimistic description in the
standard suggests.

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().

Is this true? Please tell me more - I'd be interested to hear.

I found this in the C9X Rationale (sorry, got this mixed up with the
standard itself):

"Because gets does not check for buffer overrun,
it is generally unsafe to use when its input is not
under the programmer's control. [...]"

Ok, so they have a rudimentary understanding of the problem.

"[...] This has cause some to question whether it
should appear in the Standard at all. [...]"

Classic PR -- "some to question ...". A *LOT* of people question this.
Compare to how Fox news in the US reports on things that disagree with
their bias. Anyhow, so they recognize the people who understand what's
wrong with gets() do exist. So it all looks pretty reasonable right?

"The Committee decided that gets was useful and
convenient in those special circumstances when
the programmer does have adequate control over
the input, and as longstanding existing practice,
it needed a standard specification."

Two distortions in a single sentence:

1) Any place that gets could in theory be safely used, fgets can be
safely used just as easily (if you want to be an idiot, you can even
pass in INT_MAX as the buffer length parameter). Therefore gets is not
needed (and thus neither does a specification for it) for this reason.

2) Longtime existing practice is not a justification but rather an
indictment, because it is erroneous practice.

I.e., removing gets actually *improves* the situation for *both*
reasons. The longtime existing practice needs to stop, and even under
programmer control fgets works at least as well. Black is white, up is
down, war is peace, etc. Of course they go ahead an contradict
themselves in the very next sentence:

"In general, however, the preferred function is fgets."

Ya think? In fact do you think maybe its so preferred that you should
always use it (or something even better) instead?

Do you see what they've done? They've gone ahead and presented the
main and sufficient reason for taking gets *out* of the standard, and
just pretended the logic was inverted and claimed that's why they are
leaving it *in* the standard. So if you try to bring up the issue to a
member of the the standards committee, they can point to the rationale
and claim "that issue has been addressed". As such they don't have to
explain themselves. They don't have to justify themselves, they just
have to claim the logic implies the opposite of what it really does.
If you don't get this, go read 1984.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: real time linux
    ... >> nature this type of system is open loop. ... positional command generator in the control. ... > STEP is a standard so it is possible to have certain expectations ... outside of the STEP standard and the ability to edit and compile on the ...
    (alt.machines.cnc)
  • Re: General Graphics question
    ... Standard: what you see is what you get. ... You use a standard control and override the painting ... Chris Tacke, Embedded MVP ... by the Windows graphics libraries!!!! ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: GUI primer, dos and donts
    ... business software, I don't like non-standard controls, non standard shorcuts, non standard menu captions, non standard glyphs on "standard" ... There are another "bugs" and as reason the application created by Delphi looks no good, so any experienced developer can say if app was developed in Delphi... ... is set to the first control with bad data. ... the user changes it to "bob@xxxxxxxxxxx" and the control ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: .NET vs J2EE papers
    ... >>and standard but unlike Java, MS doesn't own or control .Net. ... Windows Forms is one such part. ...
    (comp.programming)
  • Re: C Programming
    ... the language standard requires that main return ... > This as certainly not the first author of programming books to violate ... There are books around that carefully do not teach bad practice, ... the reason why I warn people about the books of Mr. Schildt is ...
    (Fedora)