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

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.

There are two reasonable ways for what you're saying to be expressed in Scheme, which calls arrays "vectors."

1. 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:

(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.

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?

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.

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...

-- 
Those who do not understand Unix are condemned to reinvent it, poorly. 	
-- Henry Spencer          <http://www.hex.net/~cbbrowne/lsf.html>
cbbrowne_at_hex.net - "What have you contributed to free software today?..."