I can't resist jumping in here. My main point is that system coding is a rather different beast than most application programming. An operating system must be able to handle memory allocation requests from a user without knowing any details of what is requested. Dennis explicitly left out a heap and garbage collection code in C because he didn't want OS code to be burdened with it. Similarly with a "real" string type (with concatenation, etc.).
An example that speaks to me is that of creating a symbol table. This isn't kernel programming, but consider what is needed:
- A structure that holds the individual table entries
- A tree of lookup tables that reflects the scoping rules of the language -- several tables might need to be searched to find an entry
- A function that looks up a name in a scope, returns the entry if it's defined, and adds a new entry in the appropriate scope if it isn't there yet.
Statistically a majority of the calls do not change the symbol table, but some do, and you can't tell in advance. And in the same way, many of the possible scopes where a variable might reside need not be searched.
So how much of this table should we copy into the lookup function? The answer seems obvious to me -- none of it...
Before Unix, Dennis and I and several other people worked on a symbolic algebra system written in FORTRAN. Dennis wrote a dynamic storage allocator, which was a real feat in FORTRAN, complete with garbage collector. The goal was to have the program work on the 6 major manufacturers' FORTRANs. We got it up and running on many of the systems, but did not have easy access to OS 360. Finally, we were granted the third shift on the OS 360, and ran our program (that had become rather solid by this time...). It was a disaster -- the brogram ran for a few second and then the OS dies and could not be restarted (turns out the core dump area allotted on the disc was not big enough to hold our program).
The problem turned out to be that the IBM compiler did copy in/copy out argument passing, while all the other compilers passed by reference. If you passed in an argument that was dynamically allocated, and the system did a garbage collection, all the elements that were still live were moved around but kept their contents intact... until the function returned, and tried to copy the changed value out where that block used to be at the time of the call.
It took us about 6 months to rewrite the system so we didn't do that -- we had to allocate everything that would be needed first, then do the work, and then free things...
None of us were fans of copy in/copy out after that experience...
Steve
----- Original Message -----
To:
"Lawrence Stewart" <stewart@serissa.com>
Cc:
"tuhs" <tuhs@minnie.tuhs.org>
Sent:
Sat, 13 May 2017 21:24:11 -0700
Subject:
Re: [TUHS] C declarations.
On Sat, 13 May 2017 21:59:57 EDT Lawrence Stewart <stewart@serissa.com> wrote:
>
> * - But I have never been able to remember the syntax for function pointers. > I always "man qsort" to refresh my memory.
The way I remember:
given *x[] or *x(), x /sticks/ to the /right/ first. Thus
int *x[]; // x is array of ptr to int
int *x(); // x is a function returning ptr to int
If you don't want a var to stick to its right, separate using
using parentheses.
int (*x)[]; // x is a ptr to array of ints
int (*x)(); // x is a ptr to function returning int
int *(*x)[]; // x is a ptr to array of ptrs to int
This sort of also works for multiple variables in one declaration. Given
int *x, y; // * /sticks/ to the right (x) first, so not available for y.
Now if they'd allowed parenthesizing the type, as in
(int *)x, y;
we would see that both x & y are of type int *. That would've also allowed
declaring multiple vars in one declaration where the previous rule applies!
(int*)(*f,*g)();
Part of the confusion is * is tacked on at the front while []
& () at the back of a variable. Someone (Chandy?) had
proposed unifying this syntax but it didn't go anywhere. I
think the author used @ in a suffix place though I don't
recall any other details. But if you put the var all the way
to the right and read a declaration right to left, it works:
int*[] x // x is a array of ptr to ints
int() f // f is a function returning it
int*()* f // f is a ptr to function returning ptr to int
int*()* f,g // f & g are ptrs to function returning ptr to int
This is only slightly weird if you are used to the current syntax
but you can easily retrain yourself.
IMHO, where evolution of C, Scheme and most programming
languages goes wrong is doing evolutionary design by
committee. Most users grasp what is easier to use vs what is
hard but they don't have the aesthetic sense or imagination or
training to make things simple. And in large groups popularity
or force of personality or some other irrelevant attribute
wins not aesthetics. Language evolution IMHO must be done by
benevolent dictatorship or a guild of like minded people who
have worked together for a long time! Go seems to have
adapted that style....