The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: <ron@ronnatalie.com>
To: "'TUHS'" <tuhs@minnie.tuhs.org>
Subject: [TUHS] C++ / Kernel
Date: Thu, 23 Aug 2018 10:42:40 -0400	[thread overview]
Message-ID: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> (raw)


> Has anyone experimented with building Unix using C++, to take
> advantage of strong typing?  My guess is no--it would be a Herculean task
likely to introduce more bugs than it would fix.

I'm not sure what "strong typing" gain you expect to find.   With the
exception of the void* difference, C++ isn't much more "type strong" than C.
A lot of the type issues you can find on the Kernel just by turning up the
compiler warnings (or use lint).

The biggest issue we had was BSD didn't use void* at all.   Had they
converted pointers to void*, which is in implementation necessarily the same
as char*,
C would have done the right thing.   The problem is they did what I call
"Conversion by union."    They would store a char* into one element of a
union and read it out of another typed pointer.
This works fine for a VAX where all pointers are the same format, but fails
on word address machines (notably in our case the HEP where the target size
is encoded in the low order bits of the pointer).
Still, running around and fixing those was only a few hours work.

The DevSwitch is the beginnings of an object oriented philosophy.   Alas,
the original UNIX used it only for mapping major dev numbers to functions.
It got some later use for other things like multi filesystemsupport.

The scary supportability thing in the kernel, isn't so much typing, but the
failuer to "hide" implementation details of one part of the kernel from the
other.


             reply	other threads:[~2018-08-23 14:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23 14:42 ron [this message]
2018-08-23 17:24 ` Clem Cole
2018-08-23 20:21 ` Bakul Shah
2018-08-23 22:17   ` ron
2018-08-23 22:28     ` Nevin Liber
2018-08-23 22:48       ` Clem Cole
2018-08-23 23:14     ` Steffen Nurpmeso
2018-08-24 14:13       ` Steffen Nurpmeso
2018-08-24 14:32         ` ron
2018-08-24 18:15           ` Steffen Nurpmeso
2018-08-26 16:34             ` Paul Winalski
2018-08-27 16:31               ` Steffen Nurpmeso
2018-08-24  1:41     ` Bakul Shah
2018-08-24 10:41       ` Pete Turnbull
2018-08-24 12:17       ` ron
2018-08-24 18:36         ` Bakul Shah
2018-08-24 18:38           ` ron
2018-08-24  1:58     ` Dan Cross
2018-08-24  3:04       ` Clem cole
2018-08-24 14:01         ` Dan Cross
2018-08-24 13:22 ` Derek Fawcus
2018-08-24 16:59   ` Steffen Nurpmeso
2018-08-23 23:29 Noel Chiappa
2018-08-23 23:42 ` ron
2018-08-24  0:30   ` Clem Cole
2018-08-24  2:05     ` Bakul Shah
2018-08-24 12:21     ` ron
2018-08-24  1:27 Noel Chiappa
2018-08-24  2:52 ` Clem cole
2018-08-24  7:30 Paul Ruizendaal

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='10c401d43aef$8be34870$a3a9d950$@ronnatalie.com' \
    --to=ron@ronnatalie.com \
    --cc=tuhs@minnie.tuhs.org \
    /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).