[moving to COFF as this has drifted away from Unix]
On Sat, Sep 28, 2024 at 2:06 PM Larry McVoy <lm(a)mcvoy.com> wrote:
> I have a somewhat different view. I have a son who is learning to program
> and he asked me about C. I said "C is like driving a sports car on a
> twisty mountain road that has cliffs and no guard rails. If you want to
> check your phone while you are driving, it's not for you. It requires
> your full, focussed attention. So that sounds bad, right? Well, if
> you are someone who enjoys driving a sports car, and are good at it,
> perhaps C is for you."
>
> If you really want a language with no guard rails, try programming in
BLISS.
Regarding C and C++ having dangerous language features--of course they do.
Every higher-level language I've ever seen has its set of toxic language
features that should be avoided if you want reliability and maintainability
for your programs. And a set of things to avoid if you want portability.
Regarding managed dynamic memory allocation schemes that use garbage
collection vs. malloc()/free(), there are some applications where they are
not suitable. I'm thinking about real-time programs. You can't have your
missle defense software pause to do garbage collection when you're trying
to shoot down an incoming ballistic missile.
-Paul W.
Moving to COFF ,..
From: "Rich Salz" <rich.salz(a)gmail.com>
To: "TUHS main list" <tuhs(a)tuhs.org>
Cc: "Douglas McIlroy" <douglas.mcilroy(a)dartmouth.edu>
Sent: Monday, September 30, 2024 4:03:15 PM
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)
On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso < steffen(a)sdaoden.eu > wrote
noone ever told them that even the eldest C can be used in a safe
way;
Perhaps we have different meanings of the word safe.
void foo(char *p) { /* interesting stuff here */ ; free(p); }
void bar() { char *p = malloc(20);
foo(p);
printf("foo is %s\n", p);
foo(p);
}
Why should I have to think about this code when the language already knows what is wrong.
No one would make the claim that programming in machine "language" is safe.
No one would make the claim that programming in assembly "language" is safe.
I've always viewed C as a portable assembler. I think the real issue has nothing to do with the "safety" of C, but rather the "safety" of your-choice-of-C-libraries-and-methods.
My $.02
Jim
FWIW, I just saw this in code generated by bison:
(yyvsp[-4].string_val), (yyvsp[-2].string_val), (yyvsp[0].string_val)
(IIUC) referencing the addresses under the top of the stack when passing
$2, $4, $6 into a function from an action (skipping a couple of
tokens). So the sign just depends on which way the stack is growing.
As for range checking of pointers into a malloc'd block of memory, the
pointer could have just 2 things: the address at the start of the block
and the pointer itself, some moving address in the block; and then
before the start of the block malloc could stash the address of the end
of the block (where it could be referenced by all pointers into the
block). So instead of a triple word, the pointer is a double word, and
the malloc'd block has an extra word before it. This must have been
done before by someone, somewhere.
I don't think of pointers and arrays in C as the same thing, but rather
array references as an alternate syntax for pointer arithmetic (or vice
versa).
- Aron
Moved to Coff, because it's about programming style, not history.
> Perhaps I'm missing something? Clever arithmetic in the index
> calculation aside, this is semantically different than using an actual
> negative integer to index into an array? Moreover, if the intent is to
> start the sequence with 0, why set `fib(0)` to 1? How is this
> substantially different from the usual way of writing this:
I said the Fibonacci example was silly. Maybe you'll be more convinced by
the binomial-coefficient program below.
The array of interest is fib. base is simply scaffolding and doesn't appear
in the working code. You won't find the ith Fibonacci in base[i]; it's in
fib(i). But fib(-1) exists. What's important is that the C convention of
array indexes beginning at 0 has been circumvented.
I could be accused of subterfuge in depending on the semantics of static
storage to initialize fib(-1) to zero. Subterfuge or not, it's customary C
usage. The binomial-coefficient program relies on "out-of-bounds" zeros
abutting two sides of a triangle.
int base[N][N+2];
#define binom(n,i) base[n][(i)+1]
void fill() {
binom(0,0) = 1;
for(n=1; n<N; n++)
for(i=0; i<=n; i++)
binom(n,i) = binom(n-1,i) + binom(n,i-1);
}
I think the offset algorithm above looks better than the more typical one
below.
The two programs happen to have identical character counts.
int binom[N][N+1];
void fill() {
for(n=0; n<N; n++) {
binom[n][0] = 1;
for(i=1; i<n; i++)
binom[n][i] = binom[n-1][i] + binom[n][i-1];
binom[n][n] = 1;
}
}
Doug
A summary of a couple of longer posts.
Ralph Corderoy and I used different C syntax than to access an MxN array A,
whose subscripts begin at M0 and N0 in the respective dimensions. Here's a
somewhat simplified version of both. In our examples, M0 and M0 were
negative.
Mine:
int base[M][N];
#define A(i,j) base[i-M0][j-N0]
Ralph's
int base[M][N];
int (*A)[N] = (int(*)[N])&base[-M0][-N0];
In my scheme element references must be written A(i,j). Ralph retains C
array syntax, A[i][j].
Doug
Mea culpa.
I thought I could offer a simple example, but my binomial-coefficient
program is wrong, and loses its force when corrected. For a convincing
example, see the program in
https://digitalcommons.dartmouth.edu/cs_tr/385/
Unfortunately you have to read a couple of pages of explanation to see what
this program is up to. It's a fun problem, though.
Doug
Moved to COFF.
On 2024-09-20 11:07, Dave Horsfall wrote (in part):
>
> Giggle... In a device driver I wrote for V6, I used the expression
>
> "0123"[n]
>
> and the two programmers whom I thought were better than me had to ask me
> what it did...
>
> -- Dave, brought up on PDP-11 Unix[*]
>
> [*]
> I still remember the days of BOS/PICK/etc, and I staked my career on Unix.
Working on embedded systems, we often used constructs such as a[-4] to
either read or modify stuff on the stack (for that particular
compiler+processor only).
S.
> I you have historical resources on Plan 9 or Inferno, or are reminded of
> any interesting tidbits, you can also share them here, as this list is
> already recognized by historians as a legitimate source.
Can someone tell me where the original "here" of the quoted message is?
Thanks,
Doug
Hi all, Edouard asked me to pass this e-mail on to both TUHS and COFF lists.
Cheers, Warren
----- Forwarded message from Edouard Klein <edouardklein(a)gmail.com> -----
Subject: History tract during the next IWMP9 in Paris next May
Date: Thu, 29 Aug 2024 22:46:30 +0200 (1 week, 4 days, 19 hours ago)
Dear Unix history enthusiasts,
The 11th International Workshop on Plan 9 will be held in Paris on May
22-24 2025.
One of the focus area this year will be Plan 9's history and its
influence on later computer science and industry trends.
The history team at the CNAM (where the conference will be held) has
agreed to help us prepare for the event and stands ready to record oral
histories, or any other format that would make the participants happy.
They had organized in 2017 a "colloque" at which Clem spoke (and I
listened somewhere in the audience) on UNIX:
https://technique-societe.cnam.fr/colloque-international-unix-en-europe-ent…
I will keep the list posted as our efforts pan out, but I thought I'd
get the word out as soon as possible.
I you have historical resources on Plan 9 or Inferno, or are reminded of
any interesting tidbits, you can also share them here, as this list is
already recognized by historians as a legitimate source.
The program committee members, many (if not all) of whom roam this very
list, would welcome any proposal or contributions in this area :)
The CfP is at:
http://iwp9.org/
Looking forward to read what you care to share, or to seeing you in
person in Paris,
Cheers,
Edouard.
----- End forwarded message -----
I just noticed this:
Sep 2018: The Multics History Project Archives were donated to the Living
Computer Museum in Seattle. This included 11 boxes of tapes, and 58 boxes of
Multics and CTSS documentation and listings. What will happen to these items
is unknown.
https://multicians.org/multics-news.html#events
That last sentence is ironic; I _assume_ it was written before the recent news.
I wonder what will happen to all such material at the LCM. Anyone know?
Noel
