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

Tor Rustad <tor_rustad@xxxxxxxxxxx> wrote:

Keith Thompson wrote:
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.

I don't think so.

In theory, he's correct. In practice, it depends on whether you think
either a predictable crash or predictable loss of data counts as "safe".
It is at least generally safer than having gets() write all over the end
of its target.

His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

No, they don't. Pointer arithmetic beyond the bounds of an object has
undefined behaviour anyway, and within an object it works fine with fat
pointers. Adding an integer to a pointer is now a matter of adding it to
a single field of the pointer structure, rather than to a flat index,
but something similar is needed with, e.g., segmented architectures.

Also, the buffer passed to gets() may not be malloc'ed, but can be an
array, or even a sub-array.

So? A sub-array simply has it recorded, in its fat pointer data, that it
is a sub-array, and what of.

Richard
.

Relevant Pages

  • Re: Python less error-prone than Java
    ... Your crash can tell you that it was a null ... Your crash can tell you that you stomped over memory. ... tell the difference between null pointer and wrong type. ... but what if you somehow lose the error message and get only ...
    (comp.lang.python)
  • Re: Date bug.
    ... Dave schreef in berichtnieuws ... > pointer to that string in the code. ... Found in a normal editor the error message, the digits of the year are showed as ...
    (comp.programming)
  • Re: Conversion from ANSI to UNICODE errors
    ... looking at the assembly, a pointer is a pointer, doesn't matter what type it ... Relvinian ... >> this compiler error message). ...
    (microsoft.public.vc.mfc)
  • Re: setting an instance of an object
    ... giving me the same error message, but it is coming in a later assignment for that same structure. ... The exact code is: ... the name `lpPweParam' suggests that it's a pointer. ...
    (microsoft.public.vc.language)
  • Re: Problem with free()
    ... The error message is somewhat more ... I know freecauses UB is passed a pointer which was not returned ... but here I never change the value of str ... int main(int argc, char **argv) ...
    (comp.lang.c)