Re: why the usage of gets() is dangerous.

CBFalconer wrote:
Malcolm McLean wrote:
"Richard Heathfield" <rjh@xxxxxxxxxxxxxxx> wrote:

It is possible, though rather difficult, to implement a safe
gets(), that is to say one that always terminates the program
with an error message if the buffer is exceeded.
Show me.
We'll declare that pointer cosist of three values - the address,
the start of the object, and the end of the object. Now in the
write to array code we specify that if the address execceds the
end of the object, the program is to terminate with an error
meaage.

No good. Pointers do not necessarily contain those components. You have to make it safe within the guarantees provided by the C
standard.

No, he doesn't. You're asking for more than Malcolm claimed.

Malcolm didn't claim that it could be made safe within the gaurantees
provided by the C standard. His claim is a much more modest one,
that it's possible for a (hypothetical) C implementation to provide a
"safe" gets() function, and I believe he's correct.

His solution requires the use of "fat pointers", which are not
widely implemented but are reasonably well understood. In such an
implementation, the char* parameter to gets() provides information
about the size of the buffer to which it points. (Portable C code
cannot make use of this information, but gets() needn't be implemented
in portable C.) If the size of the input line exceeds the size of the
buffer, the behavior is undefined. This means the implementation is
free to do whatever it likes, including terminating the program with
an error message (or discarding the remainder of the line, or leaving
the remainder of the line on the input stream).

I know of no C implementations that actually use fat pointers; even if
there were, the possibility of making gets() safe in one implementation
does no good for code that is to be used with other implementations.

I believe Malcolm's claim as stated is correct. It's not particularly
useful, but he didn't claim that it was; I believe it was merely an
intellectual excercise, not a serious proposal.


--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: why the usage of gets() is dangerous.
    ... that always terminates the program with an error message if the buffer is ... With this device we have a perfectly safe getsfucntion. ... It can only fill the buffer correctly or report that it has been exceeded. ...
    (comp.lang.c)
  • Re: why the usage of gets() is dangerous.
    ... though rather difficult, to implement a safe gets, that is to say one ... that always terminates the program with an error message if the buffer is ...
    (comp.lang.c)
  • Re: why the usage of gets() is dangerous.
    ... that is to say one that always terminates the program ... with an error message if the buffer is exceeded. ... We'll declare that pointer cosist of three values - the address, ...
    (comp.lang.c)
  • Re: why the usage of gets() is dangerous.
    ... that is to say one that always terminates the program ... with an error message if the buffer is exceeded. ... You have to make it safe within the guarantees provided by the C ... Also, the buffer passed to getsmay not be malloc'ed, but can be an array, or even a sub-array. ...
    (comp.lang.c)
  • [Full-disclosure] Re: Buffer-overflow in Ultr@VNC 1.0.1 viewer and server
    ... overflow the buffer in 3 bytes? ... the buffer is overflowed just by those 3 bytes plus the Windows ... error message created with FormatMessage. ... Limited just because the attacker has no control for executing malicious ...
    (Full-Disclosure)