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
next prev 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).