[TUHS] origins of void* -- Apology!

[imp@bsdimp.com (Warner Losh)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]

On Mon, Nov 6, 2017 at 2:46 PM, Steve Johnson <scj at yaccman.com> wrote:

> I had a senior moment when I sent out my posting about the origin of void
> *.   The person in question
> was Larry Rossler, not Charlie Roberts -- apologies to both!
>
> Larry was active in the ANSI committee, so he had a bully pulpit for
> suggesting this change...
>
> About Bliss, there certainly was a bit of a competition for a while
> between C and Bliss, and Bliss wasn't such a bad language.  But the
> technology behind it was pretty ugly.  You had to compile PDP-11 programs
> on a Dec System 20, which shut out a large percentage of the people who
> might have been interested.   And they took a very relaxed stance of
> pointer aliasing -- basically, the compiler assumed that no two pointers
> pointed to the same thing unless you turned on a flag in which case it
> assume all pointers pointed to all other pointers.  This would not have
> worked well for system code...
>
> Pascal was a much more serious competitor -- it was much easier to teach
> 75 people in a room how to program in Pascal than in C, and P-code was a
> reasonable portability mechanism.  The differences have been much discussed
> in this forum so I won't restart that thread again...
>
> At one point about 15 years after C has pretty much won over Bliss, I gave
> a job interview to a programmer at Dec who was responsible for maintaining
> 50 million lines of bliss.   I've rarely met anyone who was more determined
> to change jobs!
>

I've seen the signature "Bliss is ignorance" :)

Warner


> Steve
>
>
>
> ----- Original Message -----
> From:
> "Warner Losh" <imp at bsdimp.com>
>
> To:
> <arnold at skeeve.com>
> Cc:
> "TUHS main list" <tuhs at minnie.tuhs.org>, "Paul Ruizendaal" <pnr at planet.nl>
> Sent:
> Mon, 6 Nov 2017 08:02:53 -0700
> Subject:
> Re: [TUHS] origins of void*
>
>
>
>
> On Mon, Nov 6, 2017 at 12:24 AM, <arnold at skeeve.com> wrote:
>
>> Paul Ruizendaal <pnr at planet.nl> wrote:
>>
>> > >> In the 4BSD era there was caddr_t, which I think was used for pretty
>> > >> much the same purposes.
>> > >
>> > > Only for kernel code. I am pretty sure caddr_t wasn't used in
>> user-land code.
>> >
>> > Ah, thanks for pointing that out, I had not realised that and it helps
>> > explain some things. But why wasn’t caddr_t used for user-land code:
>> > usage in the signature of e.g. write() would have made sense, right?
>>
>> It's clear from K&R 1 that char* served as both pointer to string and
>> generic pointer to memory.  That's not unreasonable, since, in some sense,
>> "memory is just bytes".  So user-land code didn't need caddr_t.  I also
>> suspect that caddr_t came into being with the effort to port Unix off
>> the PDP-11 and the weight of Unix practice before then had been to make
>> do with char*.
>>
>> I think it helps to remember the evolutionary processes that were
>> happening
>> in the '70s.  High level languages had caught on for application code
>> (FORTRAN and COBOL in the US, Algol in Europe) but the weight of existing
>> practice for *systems coding* (operating systems and utilities) had been
>> to use assembly language.  Multics proved that you could write an OS in
>> a high level language, but Multics itself (at that time) wasn't a success.
>>
>> So when C came along in the mid-'70s, strong typing had essentially been
>> absent from systems programming.  With time and experience, along with
>> the recognition in the general CS world that strong typing was valuable,
>> C also started to evolve in that direction.
>>
>
> I thought there'd also been some influences from BLISS... DEC did much of
> their system programming in BLISS along side the MACRO-{11,32,20}....  Not
> exactly a strongly typed language, but another entry in the higher level
> language category that C was competing against.
>
> Warner
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/5efd365c/attachment-0001.html>