The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Perry E. Metzger" <perry@piermont.com>
To: Paul Winalski <paul.winalski@gmail.com>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] About Unix header files
Date: Wed, 22 Aug 2018 11:46:30 -0400	[thread overview]
Message-ID: <20180822114630.31557ebe@jabberwock.cb.piermont.com> (raw)
In-Reply-To: <CABH=_VRaKv-yn8VFXbxuUGN8=KeM-=_tNtBaoQGFQZsDesBjjA@mail.gmail.com>

On Wed, 22 Aug 2018 11:29:40 -0400 Paul Winalski
<paul.winalski@gmail.com> wrote:
> On 8/22/18, Perry E. Metzger <perry@piermont.com> wrote:
> >
> > To my knowledge, object file formats still don't have information
> > about type signatures, and linkers still don't care about types.
> > This is actually a problem. It would probably prevent a lot of
> > errors if those things changed.
> 
> For a linker to enforce (or warn about) type and call signature
> matching, it would have to know the type and call semantics of each
> particular language,

Not necessarily. One could produce a language-independent way of
signaling what the type signatures are (perhaps with normalized
language-dependent strings) and the linker could just check that they
match.

I've seen several languages (like OCaml) hack around the lack of this
by providing an auxiliary file for a pre-link phase to check off
of. It would be nicer if the linker could just handle that.

And, as I noted, this would doubtless prevent a _lot_ of bugs.

One could simply decorate the symbols with a
(language, semi-opaque "type string") pair, and the linker could just
verify that they matched without understanding semantics.

> Not impossible, but a difficult and cumbersome problem, particularly
> as language and compiler implementation semantics vary over time.

As I noted, there are ways to get around that.

> C++ and other strongly-typed languages typically hack around the
> problem using name decoration.  Not elegant, but effective.

Name mangling for C++ is needed for another reason, too, which is that
a single "name" foo might be multiple different concrete functions
depending on what type it is invoked on.

> 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.

C++ doesn't have strong typing in the modern sense. It also has some
small incompatibilities with C's syntax and semantics, sufficient that
you can't just (say) compile the Linux kernel with a C++ compiler and
have it work.

Perry
-- 
Perry E. Metzger		perry@piermont.com

  parent reply	other threads:[~2018-08-22 15:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-21  4:55 Caipenghui
2018-08-21  6:00 ` Warren Toomey
2018-08-21 21:37 ` Cornelius Keck
2018-08-22  4:25   ` [TUHS] Cornelius Keck Caipenghui
2018-08-22 13:44   ` [TUHS] About Unix header files Perry E. Metzger
2018-08-22 15:29     ` Paul Winalski
2018-08-22 15:36       ` Caipenghui
2018-08-22 15:46       ` Perry E. Metzger [this message]
2018-08-22 15:52         ` G. Branden Robinson
2018-08-22 15:56         ` Paul Winalski
2018-08-22 16:04     ` Dan Cross
2018-08-23  2:23       ` George Michaelson
2018-08-22 22:00 Doug McIlroy
2018-08-22 23:05 ` Erik E. Fair

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=20180822114630.31557ebe@jabberwock.cb.piermont.com \
    --to=perry@piermont.com \
    --cc=paul.winalski@gmail.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).