The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah via TUHS <tuhs@tuhs.org>
To: Richard Salz <rich.salz@gmail.com>
Cc: TUHS main list <tuhs@tuhs.org>,
	Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)
Date: Mon, 30 Sep 2024 15:14:38 -0700	[thread overview]
Message-ID: <A940C1B3-AA15-4AB4-9433-A2E7150BBBB7@iitbombay.org> (raw)
In-Reply-To: <CAFH29tp4fZR7ct57F-BmyqoJwwRfHkSbiVPS1mj89e-_gzhsHQ@mail.gmail.com>

On Sep 30, 2024, at 1:03 PM, Rich Salz <rich.salz@gmail.com> wrote:
> 
> 
> On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso <steffen@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.

The language doesn't know! The compiler can't know without the programmer
indicating this somehow, especially if foo() is an extern function.

I am still interested in making C safer (to secure as best as possible
all the zillions of lines of C code in OS kernels). The question is, can
we retrofit safety features into C without doing major violence to it
& turning it into an ugly mess? No idea if this is even feasible but seems
worth exploring with possibly a great ROI.

Take the above code as an example. It is "free()" that invalidates the
value of its argument on return and this property is then inherited by its
callers. One idea is to declare free as follows:

void free(`zap void*ptr); // `zap is says *ptr will be invalid on return

Now a compiler can see and complain that foo() will break this and
insist that foo() too must express the same thing. So we change it to

void foo(`zap char* p) { ... free(p); }

Now the compiler knows p can't dereferenced after calling foo() and can
complain on seeing p being printf'ed.

This was just an example of an idea -- remains to be seen if it amounts to
anything useful. In an earlier email I had explored bounds checking. Clearly
all such extensions would have to play well together as well as with the
existing language. My hope is that the language can be evolved in this way
and gradually kernel code can be fixed up to benefit from it.

Bakul


  parent reply	other threads:[~2024-09-30 22:15 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-29 16:56 [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) Douglas McIlroy
2024-09-29 20:29 ` Rob Pike
2024-09-29 21:13   ` Rik Farrow
2024-09-29 22:21   ` Rich Salz
2024-09-29 23:56     ` Rob Pike
2024-09-30  0:36       ` Larry McVoy
2024-09-30  0:55         ` Larry McVoy
2024-09-30  1:09         ` Luther Johnson
2024-09-30  1:37           ` Luther Johnson
2024-09-30  3:52             ` ron minnich
2024-10-01 12:43             ` arnold
2024-09-30 19:12   ` Steffen Nurpmeso
2024-09-30 20:03     ` Rich Salz
2024-09-30 21:15       ` Steffen Nurpmeso
2024-09-30 22:14       ` Bakul Shah via TUHS [this message]
2024-10-01  1:42         ` Alexis
2024-09-30 20:14     ` Rik Farrow
2024-09-30 22:00       ` Steffen Nurpmeso
2024-10-01 12:53       ` Dan Cross
2024-11-18 12:00         ` Anton Shepelev
2024-11-18 12:46           ` Luther Johnson
2024-11-18 14:05             ` Steve Nickolas
2024-11-18 15:00               ` Anton Shepelev
2024-11-23 22:29                 ` Alexander Schreiber
2024-11-18 14:55             ` Anton Shepelev
2024-11-18 16:52               ` G. Branden Robinson
2024-11-18 17:00                 ` Anton Shepelev
2024-11-18 18:56                 ` Luther Johnson
2024-11-22  1:53           ` Dan Cross
2024-11-22  2:55             ` Luther Johnson
2024-09-29 21:24 ` Ralph Corderoy
  -- strict thread matches above, loose matches on Subject: below --
2024-09-28 13:34 Douglas McIlroy
2024-09-28 16:58 ` G. Branden Robinson
2024-09-28 17:47   ` Luther Johnson
2024-09-28 17:52     ` Luther Johnson
2024-09-28 18:46       ` G. Branden Robinson
2024-09-28 22:08         ` Luther Johnson
2024-09-28 22:45           ` Luther Johnson
2024-09-28 22:50             ` Luther Johnson
2024-09-28 17:59   ` Bakul Shah via TUHS
2024-09-28 22:07     ` Douglas McIlroy
2024-09-28 23:05       ` Rob Pike
2024-09-28 23:30         ` Warner Losh
2024-09-29 10:06           ` Ralph Corderoy
2024-09-29 12:25             ` Warner Losh
2024-09-29 15:17               ` Ralph Corderoy
2024-09-30 12:15           ` Dan Cross
2024-09-28 18:01   ` G. Branden Robinson
2024-10-01 13:13     ` arnold
2024-10-01 13:32       ` Larry McVoy
2024-10-01 13:47         ` arnold
2024-10-01 14:01           ` Larry McVoy
2024-10-01 14:18             ` arnold
2024-10-01 14:25             ` Luther Johnson
2024-10-01 14:56               ` Dan Cross
2024-10-01 15:08                 ` Stuff Received
2024-10-01 15:20                 ` Larry McVoy
2024-10-01 15:38                   ` Peter Weinberger (温博格) via TUHS
2024-10-01 15:50                     ` ron minnich
2024-10-01 19:04                 ` arnold
2024-10-01 16:49           ` Paul Winalski
2024-10-01 15:44       ` Bakul Shah via TUHS
2024-10-01 19:07         ` arnold
2024-10-01 20:34           ` Rik Farrow
2024-10-02  0:55             ` Steffen Nurpmeso
2024-10-02  5:49             ` arnold
2024-10-02 20:42               ` Dan Cross
2024-10-02 21:54                 ` Marc Donner
2024-10-05 17:45                 ` arnold
2024-10-06 12:20                   ` Dan Cross
2024-10-01 16:40       ` Paul Winalski
2024-09-28 18:05   ` Larry McVoy
2024-09-30 15:49     ` Paul Winalski

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=A940C1B3-AA15-4AB4-9433-A2E7150BBBB7@iitbombay.org \
    --to=tuhs@tuhs.org \
    --cc=bakul@iitbombay.org \
    --cc=douglas.mcilroy@dartmouth.edu \
    --cc=rich.salz@gmail.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).