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

James Kuyper wrote:
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.

I think my major point is that, wherever I look, I see continuously
building auxiliary data combined with cpu-eating indirect pointer
accesses.

I also maintain that it has to work all the time. Otherwise the
fact that it passes gives one no confidence whatsoever, and the odd
pass just encourages ignoring the real problem. How many time do
you hear 'It works on my machine' as the excuse/justification for
poor code?

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

.

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. ... 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. ... relatively straightforward fat pointer implementation that is only moderately inefficient can't protect against every possible problem. ...
    (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)