Re: More benchmark bullshit, and Linux luser mating calls... (was Re: Linux betas NT in TPC testing, running Oracle8

On Fri, 30 Apr 1999 04:12:03 GMT, cbbrowne_at_news.brownes.org (Christopher B. Browne) wrote:

>On Thu, 29 Apr 1999 17:22:05 GMT, Anthony Ord
><nws_at_rollingthunder.demon.co.uk> posted:
>>On Wed, 28 Apr 1999 00:20:45 GMT, cbbrowne_at_news.hex.net
>>(Christopher Browne) wrote:
>>
>>>On 27 Apr 99 21:58:41 GMT, David Brower <dbrower_at_us.oracle.com> wrote:
>>>>nws_at_rollingthunder.demon.co.uk (Anthony Ord) writes:
>>>>>>How can pointers in structures be naughty?
>>>>
>>>>>Can someone point out how to do linked lists and binary
>>>>>trees without them?
>>>>
>>>>(a) Array indeces
>>>>(b) object references (which need not be pointers)
>>>>
>>>>Pointers as used in C are inherently "unsafe", though it is
>>>>silly to complain about this as a Linux problem. It's not
>>>>like many of the competitive OSes are written in something
>>>>else that is "better"
>>
>>They are unsafe, but they are how a computer works.
>>
>>>Handling references via arrays, and treating positions in the array as
>>>indices requires pointer management every bit as much as a scheme that
>>>has the pointers look upon "raw memory." With the upside that
>>>out-of-bounds conditions may possibly be caught by the language's run
>>>time system rather than having to rely on hardware.
>>
>>Not necessarily. If you access array[714] when you "deleted"
>>entry 714, your application will romp merrily on with the
>>wrong data. With pointers Captain SEGV leaps up and says
>>"You can't do that!" (Sometimes).
>
>I'm not sure that makes sense.
>
>If I've deleted entry 714 in an array, which mandates some equivalent
>to realloc(), the runtime system should be quite aware that the array
>now has less than 714 elements, and hence cannot reference #714
>anymore.

No.

Imagine you have a linked list.

512->714->986 and you delete the entry such that your linked list is now 512->986. If it is an array, then 714 is still there. Alive, yet not alive (like Leonard Cohen).

>There are two reasonable ways for what you're saying to be expressed
>in Scheme, which calls arrays "vectors."
>
>a) I might delete the *contents* of entry 714.
>
>(define V (make-vector 800 'a))
>(define V (do-things-to-vector V))
>(vector-set! V 714 #f) ; Nuke entry 714
>
>In this case, all that happens is that the entry is empty. Neither
>Captain SEGV nor runtime system would flag an error at a reference to
>entry #714:

Which is not very good.

>(vector-ref V 714)
>#f
>
>The program may freak at #f, but that's not a pointer problem, at
>least not one relating to the vector V.
>
>b) I might decide to resize the vector to some smaller size.
>
>There's not a standard R5RS call for this, but it might be done like:
>(define V (make-vector 800 'a))
>(define V (do-things-to-vector V))
>(define V (vector-resize V 700)) ; Nuke the last hundred entries
>
>At this point, a reference to the 714th entry returns something like:
>(vector-ref v 714)
>ERROR: In procedure vector-ref in expression (vector-ref v 800):
>ERROR: Argument out of range: 800
>ABORT: (out-of-range)
>
>Which is nicely trapped by the runtime system.

But it only works if the stuff you delete is off the end.

>Or are you thinking about some other data structure, such as a list,
>or an associative array, both of which are capable of being used to
>simulate arrays?

No. I'm thinking about a linked list being simulated by an array. (for the sole purpose of avoiding pointers).

>Both of those should also permit errors to be caught either by runtime
>system or by "Captain SEGV," depending on strategy.
>
>>Upside of pointers: You don't need large areas of contiguous
>>memory - this is less important with modern virtual memory
>>systems - assuming you *can* use virtual memory.
>>
>>Downside of pointers: Memory fragmentation if you are
>>careless or lazy.
>>
>>>Of course, if the hardware supports bounds checking nicely, it may be
>>>better to let the hardware manage it...
>>>
>>>And "object references" wind up as references to memory at *some*
>>>point.
>>
>>Yes, with the added attraction of not having to use ^. Which
>>isn't really a bind at all.
>
>That just means that the "^" is being bound by lower levels of the
>system... There be evil puns there...
>
>>>When implementing an operating system, you have a choice:
>>>a) You can have pointer manipulations pervade the system, or
>>>
>>>b) You can construct some "reference management" section (aka "library"
>>>aka "module") that is *totally* pervaded by pointer manipulations, and
>>>have the rest of the system implicitly use the pointer manipulations
>>>from the "reference management module."
>>
>>#defines?
>
>That's one possibility; il n'importe quoi.
>
>I couldn't care less *what* scheme is used; if pointers are avoided at
>one level, they'll pervade somewhere else.

I totally agree.

>A microkernel system may mean that the singleserver/multiserver
>doesn't need to have grungy hardware access code; that just means that
>the grungy stuff is forced into the microkernel.
>
>>>Note that in neither case do you get to avoid having to do grungy work
>>>of pointer manipulations.
>>
>>It's virtually impossible to avoid when you have to
>>implement everything from banging on the metal upwards.
>
>When what we're talking about is the part that "bangs on the metal,"
>it's not merely a virtual impossibility, but an actual example
>thereof...

Regards

Anthony

-- 
-----------------------------------------
| And when our worlds                   |
| They fall apart                       |
| When the walls come tumbling in       |
| Though we may deserve it              |
| It will be worth it  - Depeche Mode   |
-----------------------------------------