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

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

You've completely missed the point here. Re-read the sentence "If I know
that on my system int is 17 bits or more, I can guarantee I haven't [invoked
UB when adding 32767 to 1]".

What relevance is that? The C standard says nothing about such
guarantees. You are comflating a particular implementation with the
standard. Of course an implementation can do whatever it wants for
platform-specific and undefined behavior. So it does -- this does not
prove any point.

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

http://en.wikipedia.org/wiki/Begging_the_question

That does not apply here. That gets() comes with UB is not in dispute.
That you can remove its undefinedness on a particular platform, is
nothing more than an abuse of the meaning of the word UB.

into one narrow manifestation or predictable
behavior. That's exactly what I did in my sample implementation, BTW.

Except that yours isn't standard-compliant.

Of course it is -- under conditions of UB any behavior is
standard-compliant.

[...] gets() does not invoke UB unless
it actually overruns the buffer.

But nothing in the program can make this condition either happen or not
happen. I.e., to be well defined the spec has to specify something
outside of the C language. Besides not being its mandate -- it
actually does not do that. So the specification does not describe
conditions within the confines of what its describing (that C language,
not what user should do) under which the call can be made to be well
defined. The "unless its actually overruns the buffer" is nothing that
the C standard can explain with any specificity -- and it doesn't try.

[...] If you believe otherwise, quote C&V, rather
than just asserting it.

Quoting from the standard is useless since the standard does not make
any attempt to analyze things to their logical conclusion. Taking a
classic cue from Keith Thomspon, if you narrow your view of C
programming to just the spec you would conclude that the C language
does not contain variables (I kid you not, he posted this). Or as
other people keep claiming -- that C doesn't have a stack (if function
calls and returns are always bracketted like pushes and pops, do we not
have a stack? In fact a "call" stack?).

But telling me to justify my "beliefs" by citing chapter and verse you
are just being like the standards committee was with the gets()
rationale by attempting to subvert the rules for the argument.

Buffer overruns invoke UB. gets() may invoke buffer overruns
independent of how the programmer uses it. In some implementations its
possible to go outside the ANSI specification to force gets() to not
buffer overflow and have the behavior that's described in the spec,
however clearly the spec does not delineate these conditions.

So regardless of what the spec says under the heading of gets(), the UB
is inescapable from within the spec, which means the behavior described
in the spec is irrelevant since UB can invoke any behavior.

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

.

Relevant Pages

  • Re: Unix I/O and C library I/O, why there are two sets of I/O functions?
    ... whereas readgives you no such guarantee. ... as far as fread() is concerned - the bytes ... that would be a "partial item" are still in the buffer, ... with a closer reading of the standard i'll concede that it's ...
    (comp.lang.c)
  • Re: CString help
    ... But maybe because I don't see the guarantee of contigous space ... the fact remains that the technique writes into a buffer ... Even if the buffer is required to be contigous by the standard, ...
    (microsoft.public.vc.mfc)
  • Re: Great SWT Program
    ... And the emacs term "buffer" is not identical to this. ... Emacs generally doesn't care about your own standard. ... launching "flashlight" is still carrying a concealed gun. ...
    (comp.lang.java.programmer)
  • Re: WaitForSingleObject() will not deadlock
    ... But what is TSO? ... Technical Standard Order, a minimum performance standard issued by the FAA for certain ... have been more commonly referred to as the "cache coherency" ... A mutex is sufficient to guarantee visibility, ...
    (microsoft.public.vc.mfc)
  • Re: Buffer overflows and asctime()
    ... to contain a "bug" as others are not. ... standard the year member receives a maximum value. ... will overflow its buffer if confronted with valid inputs. ... So you still do not understand "undefined behavior". ...
    (comp.std.c)