Re: [TUHS] About Unix header files

Re: [TUHS] About Unix header files

[Doug McIlroy]

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

How Unix didn't get written in C++:

When Bjarne Stroustrup joined Bell Labs, he hoped to write an
operating system, but he wanted to do it in an object oriented
language, so he took a small detour to make an object-oriented
sibling of C. That turned out to be a maelstrom from which he
never escaped. 

Doug

Re: [TUHS] About Unix header files

[Erik E. Fair]

I will never forget what dmr said in response to a question about C++ at a USENIX conference long ago:

"Bjarne and I have an agreement: I don't talk about C++, and he doesn't talk about 'old C'."


	Erik Fair

[TUHS] About Unix header files

[Caipenghui]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

Hello everyone

Hello everyone, I have a question, I looked at the source code of early Unix, found that a lot of.c files did
not contain header files, so compiler compiler will not error?

Caipenghui

[-- Attachment #2: Type: text/html, Size: 225 bytes --]

Re: [TUHS] About Unix header files

[Warren Toomey]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

And just a note that Caipenghui is new to the list, he is from China and dmr is one of his heroes.
Cheers, Warren
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 200 bytes --]

Re: [TUHS] About Unix header files

[Cornelius Keck]

[-- Attachment #1: Type: text/html, Size: 4568 bytes --]

Re: [TUHS] About Unix header files

[Perry E. Metzger]

On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck@texoma.net>
wrote:
> Early C-compilers didn't care much about prototypes. The default
> return type of a function would be an int. It was up to the code's
> author to pass the right (amount, order, type). The linker didn't
> care about signatures as long as the symbol resolved.

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.

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

Re: [TUHS] About Unix header files

[Paul Winalski]

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, and each particular compiler's switch options
that allow the programmer to bend the language rules.  Not impossible,
but a difficult and cumbersome problem, particularly as language and
compiler implementation semantics vary over time.

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

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.

-Paul W.

Re: [TUHS] About Unix header files

[Caipenghui]

On August 22, 2018 11:29:40 PM GMT+08:00, 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, and each particular compiler's switch options
> that allow the programmer to bend the language rules.  Not impossible,
> but a difficult and cumbersome problem, particularly as language and
> compiler implementation semantics vary over time.
>
> C++ and other strongly-typed languages typically hack around the
> problem using name decoration. Not elegant, but effective.
>
> 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.
>
> -Paul W.

Well, I agree with you that this may be achieved in the future.

Re: [TUHS] About Unix header files

[Perry E. Metzger]

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

Re: [TUHS] About Unix header files

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

At 2018-08-22T11:46:30-0400, Perry E. Metzger wrote:
> 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.

My impression is that Ada's .ali (I haven't seen an official mnemonic,
but "Ada Link Information" seems likely) files provide this security.

-- 
Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [TUHS] About Unix header files

[Paul Winalski]

On 8/22/18, Perry E. Metzger <perry@piermont.com> wrote:
>
> 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.

True.  And the debugger people have already done the design work in
this area.  One could probably use DWARF to pass this info to a
linker.

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

I'm pretty sure that is how VMS Ada solved the problem, too.

-Paul W.

Re: [TUHS] About Unix header files

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger <perry@piermont.com> wrote:

> On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck@texoma.net>
> wrote:
> > Early C-compilers didn't care much about prototypes. The default
> > return type of a function would be an int. It was up to the code's
> > author to pass the right (amount, order, type). The linker didn't
> > care about signatures as long as the symbol resolved.
>
> 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.
>

One can embed type information in existing object file formats (e.g. ELF)
by placing it in dedicated sections. This is what Go does, for example. The
Go linker does some type analysis for reflection, though if symbols line up
it does not detect or prevent e.g. signature mismatches.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1393 bytes --]

Re: [TUHS] About Unix header files

[George Michaelson]

That Go decision feels like something which could be built upon.

I think this already moving off TUHS but none the less, looking
forward, the increase in strongly typed languages in use points to a
desire to preserve the type semantics so that inter-language linking
can maintain the promises (so to speak)

If Go has gone to marking the promises around types in a useful way, I
would be entirely cool if somebody smart in llvm said "oh, if you
layer your language compiler onto our STL and ISA model, our
intermediate code representation then ... " (I believe GHC
deliberately does this, and Frege targets the JVM similarly)

Smart people in small groups do huge things which have big
consequence. I am not a Go person, I tried and failed for purely
personal reasons. If Go takes the underlying abstract ideas and does
something other people can leverage, I would be very applauding. I
like that kind of outcome.

-G
On Thu, Aug 23, 2018 at 2:05 AM Dan Cross <crossd@gmail.com> wrote:
>
> On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger <perry@piermont.com> wrote:
>>
>> On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck@texoma.net>
>> wrote:
>> > Early C-compilers didn't care much about prototypes. The default
>> > return type of a function would be an int. It was up to the code's
>> > author to pass the right (amount, order, type). The linker didn't
>> > care about signatures as long as the symbol resolved.
>>
>> 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.
>
>
> One can embed type information in existing object file formats (e.g. ELF) by placing it in dedicated sections. This is what Go does, for example. The Go linker does some type analysis for reflection, though if symbols line up it does not detect or prevent e.g. signature mismatches.
>
>         - Dan C.
>