From: scj@yaccman.com (Steve Johnson)
Subject: [TUHS] C declarations.
Date: Sat, 13 May 2017 23:12:45 -0700 [thread overview]
Message-ID: <e07f3d95ccda301190c64337424f49d8a0713316@webmail.yaccman.com> (raw)
In-Reply-To: <20170514042411.93CCB124AEA4@mail.bitblocks.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5335 bytes --]
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 -----
From: "Bakul Shah" <bakul@bitblocks.com>
To:"Lawrence Stewart" <stewart at serissa.com>
Cc:"tuhs" <tuhs at 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 at 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....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170513/19d1420b/attachment.html>
next prev parent reply other threads:[~2017-05-14 6:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 21:49 Ron Natalie
2017-05-11 22:01 ` Arthur Krewat
2017-05-11 23:44 ` Dave Horsfall
2017-05-11 22:03 ` David Arnold
2017-05-11 22:32 ` Larry McVoy
2017-05-11 22:41 ` Ron Natalie
2017-05-13 1:24 ` Larry McVoy
2017-05-13 2:45 ` Ron Natalie
2017-05-13 12:20 ` Michael Kjörling
2017-05-13 12:35 ` Tim Bradshaw
2017-05-13 12:42 ` Michael Kjörling
2017-05-13 15:36 ` Stephen Kitt
2017-05-14 1:59 ` Lawrence Stewart
2017-05-14 2:23 ` Dave Horsfall
2017-05-14 4:24 ` Bakul Shah
2017-05-14 6:12 ` Steve Johnson [this message]
2017-05-14 6:48 ` Bakul Shah
2017-05-14 23:06 ` Ron Natalie
2017-05-14 23:34 ` Arthur Krewat
2017-05-15 0:14 ` Dan Cross
2017-05-15 0:23 ` Ron Natalie
2017-05-15 3:43 ` Random832
2017-05-15 0:40 ` Larry McVoy
2017-05-15 2:00 ` Nevin Liber
2017-05-15 10:21 ` Tony Finch
2017-05-15 4:35 ` Dave Horsfall
2017-05-15 4:54 ` Bakul Shah
2017-05-15 5:01 ` Dave Horsfall
2017-05-15 12:58 ` Michael Kjörling
2017-05-15 16:58 ` Dave Horsfall
2017-05-15 19:00 ` [TUHS] cdecl (Re: " Bakul Shah
2017-05-15 22:52 ` Dave Horsfall
2017-05-13 13:46 ` [TUHS] " Hellwig Geisse
2017-05-13 19:08 ` Random832
2017-05-13 23:21 ` Dave Horsfall
2017-05-14 14:48 ` Nemo
2017-05-13 19:05 ` Random832
2017-05-14 13:14 ` Derek Fawcus
2017-05-12 0:15 ` Bakul Shah
2017-05-12 2:41 ` Theo Pavlidis
2017-05-12 14:04 Richard Tobin
2017-05-13 23:11 Richard Tobin
2017-05-15 6:46 ` Tim Bradshaw
2017-05-14 14:11 Doug McIlroy
2017-05-14 14:58 ` Steve Nickolas
2017-05-15 18:47 Steve Johnson
2017-05-15 19:54 ` Bakul Shah
2017-05-16 7:25 ` George Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e07f3d95ccda301190c64337424f49d8a0713316@webmail.yaccman.com \
--to=scj@yaccman.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).