21 Aug
2018
21 Aug
'18
4:55 a.m.
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
21 Aug
21 Aug
6 a.m.
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.
22 Aug
22 Aug
4:25 a.m.
New subject: Cornelius Keck
On August 22, 2018 5:37:43 AM GMT+08:00, Cornelius Keck <ckeck(a)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.
What one did need were struct definitions and macros, such as getchar,
putchar, min, max, abs, because they might not be provided by some
library, causing link to fail.
Back then one could get away with constructs creative enough to make a
modern compiler blow a gasket, and it would all run just fine, as long
as one didn't accidentally drop a bunch of bits when typecasting, and
sizeof(int) = sizeof(int*).
Those were interesting times. I do miss them.
Gesendet von meinem BlackBerry 10-Smartphone.
Von: Caipenghui
Gesendet: Dienstag, 21. August 2018 00:12
An: tuhs(a)minnie.tuhs.org
Betreff: [TUHS] About Unix header files
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
We miss DMR. DMR is dead, but we
will not forget his contribution to
humanity. We will learn a simple humorous spirit of DMR. Not only did he teach us to code,
he seemed to convey a human spirit. DMR also conveys the spirit of Unix philosophy, such
as kiss.do a thing, do it well, etc.
Caipenghui
1:44 p.m.
On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck(a)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(a)piermont.com
3:29 p.m.
On 8/22/18, Perry E. Metzger <perry(a)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.
3:36 p.m.
On August 22, 2018 11:29:40 PM GMT+08:00, Paul Winalski
< paul.winalski(a)gmail.com> wrote:
Well, I agree with you that this may be achieved in the future.
On 8/22/18, Perry E. Metzger
<
perry(a)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.
3:46 p.m.
On Wed, 22 Aug 2018 11:29:40 -0400 Paul Winalski
<paul.winalski(a)gmail.com> wrote:
On 8/22/18, Perry E. Metzger
<perry(a)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.
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.
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 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(a)piermont.com
3:52 p.m.
At 2018-08-22T11:46:30-0400, Perry E. Metzger wrote:
On Wed, 22 Aug 2018 11:29:40 -0400 Paul Winalski
<paul.winalski(a)gmail.com> wrote:
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
On 8/22/18, Perry E. Metzger
<perry(a)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.
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.
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,
3:56 p.m.
On 8/22/18, Perry E. Metzger <perry(a)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.
4:04 p.m.
On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger <perry(a)piermont.com> wrote:
On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck
<ckeck(a)texoma.net>
wrote:
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.
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.
23 Aug
23 Aug
2:23 a.m.
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(a)gmail.com> wrote:
On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger <perry(a)piermont.com> wrote:
On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck(a)texoma.net>
wrote:
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.
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.
2072
days inactive
2074
days old
11 comments
8 participants
participants (8)
-
Caipenghui -
Cornelius Keck -
Dan Cross -
G. Branden Robinson -
George Michaelson -
Paul Winalski -
Perry E. Metzger -
Warren Toomey