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

CBFalconer wrote:
Chris Torek wrote:
Richard Bos <rlb@xxxxxxxxxxxxxxxxxxxxxx> wrote:

... you do need to link fat-pointer-compiled object files with
fat-pointer-compiled libraries; much as you need to link 64-bit
object files with 64-bit libraries, little-endian object files
with little-endian libraries, and on MS-DOS used to link large
memory model object files with large memory model libraries.
... snip ...
In general, the simplest method is to have all "fat pointers"
represented as a triple: <currentvalue, base, limit>. A pointer
is "valid" if its current-value is at least as big as its base
and no bigger than its limit:

Just picking on one thing, based on it has to work everywhere, or
it is useless.

We're talking about use of fat pointers as a device to protect against memory bounds violation. Protection doesn't have to be perfect to be useful. A bullet-proof vest won't protect against a head shot, washing your hands before a meal won't protect you against airborne diseases, the best available contraceptive measures still occasionally fail. That doesn't make those protective measures useless.

A simple, relatively straightforward fat pointer implementation that is only moderately inefficient can't protect against every possible problem. It could protect against use of pointer arithmetic to create a pointer to a position before the beginning, or more than one position after the end, of the relevant array. It can also protect against any attempt to access positions one past the end of the array. Providing more complete protection requires a more complicated or inefficient mechanism; but that doesn't make the simpler protection mechanism useless.

....
I have made my share of mistakes in code-generation, and I want
things simple and consistent.

Fat pointers are not as simple to implement as ordinary pointers, and I would imagine that retrofitting an implementation originally designed to use ordinary pointers would be a bug-prone process. However, it's nowhere near to being the most complicated feature that real C compilers have implemented successfully.
.

Relevant Pages

  • Re: why the usage of gets() is dangerous.
    ... object files with 64-bit libraries, ... memory model object files with large memory model libraries. ... We're talking about use of fat pointers as a device to protect against ... relatively straightforward fat pointer implementation that is ...
    (comp.lang.c)
  • Re: Strong thread safety and lock free?
    ... I can't get how you protect against that overflow... ... As far as I have seen your code did not have any protection against overflow too. ... And furthermore you have to be careful with aliasing, because when a thread has more than one local pointer taken from the same shared pointer you need bits for more than the number of threads. ... delete obj; ...
    (comp.programming.threads)
  • Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.
    ... protect against freeing. ... whenever the reader fetches an element in a list. ... You will also need the ACCESS_ONCEon the pointer fetch in order ... are not only for RCU. ...
    (Linux-Kernel)
  • Re: Pointer operations
    ... > Macca wrote: ... This pointer is of type Class B and does various data processing. ... is a variable in Class B that i want to be able to manipulate from another ... then you will need to protect the variable with ...
    (microsoft.public.vc.mfc)
  • Re: why the usage of gets() is dangerous.
    ... object files with 64-bit libraries, ... memory model object files with large memory model libraries. ... If a pointer is malloced, ...
    (comp.lang.c)