[TUHS] origins of void*

[TUHS] origins of void*

[Doug McIlroy]

As has been explained, void came from Algol 68 via Steve Bourne.
As no object could be declared void, void* was a useless
construct. A kind of variable that could point to any object
was required to state the type of useful functions like qsort.
To avoid proliferation of keywords, the useless void* was
pressed into service. I do not remember who suggested that.

Doug

[TUHS] origins of void*

[Steve Johnson]

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

I tried to post this once, but it doesn't seem to have worked. 
 Apologies if you see this twice...

Steve

--------------------------

Ok, here's my memory of void *, blurred as it may be by time.

Void was put into C, but it was actually not necessary by itself --
the default return type was int, and if nobody was using the value
there was no particular reason to use void.  So only those who were
practitioners of the strong-type religion tended to use it.  A major
problem in making C strongly typed was deciding on a return type for
malloc.  It had traditionally returned char *, but this required a
cast to allow you to allocate things other than characters.

I was at a /usr/grp conference at the alcohol-fueled reception talking
to Charlie Roberts about the problems of making C more strongly
typed.  The topic of malloc came up.  All of a sudden Charlie got a
huge grin on his face and said "Hey!  Why don't we have malloc return
void *".   It took me a minute or two to even understand what void *
could possibly mean, but the idea was an instant winner.   I seem to
recall it was done a week or two later.   The idea may have simply
ready to be born and others may have had it as well, but this is what
I remember of it.  And the experience sticks in my mind as being an
almost literal example of being "struck by an idea".

Steve

------------------------

----- Original Message -----
From:
 "Doug McIlroy" <doug at cs.dartmouth.edu>

To:
<tuhs at minnie.tuhs.org>
Cc:

Sent:
Sun, 05 Nov 2017 19:37:16 -0500
Subject:
Re: [TUHS] origins of void*

 As has been explained, void came from Algol 68 via Steve Bourne.
 As no object could be declared void, void* was a useless
 construct. A kind of variable that could point to any object
 was required to state the type of useful functions like qsort.
 To avoid proliferation of keywords, the useless void* was
 pressed into service. I do not remember who suggested that.

 Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/5971880e/attachment.html>

[TUHS] origins of void*

[Noel Chiappa]

    > From: Clem Cole

    > typing hard started to become more important in the kernel.

I can imagine! The V6 kernel had all sorts of, ah, 'unusual' typing - as I
learned to my cost when I did that hack version of 'splice()' (to allow a
process in a pipline to drop out, and join the two pipes together directly),
which I did in V6 (my familiar kernel haunt).

Since a lot of code does pointer math to generate wait 'channel' numbers,
e.g.:

  sleep(ip+2, PPIPE);
  
when I naively (out of habit) tried to declare my pointers to be the correct
type, the math didn't work any more! ('ip', in this particular case, was
declared to be an 'int *'.)

No doubt part of this was inherited from older versions (of the system, and
C); the code was working, and there was no call to tweak it. The lack of
casts/coercion in the V6 C compiler may have been an issue, too - I had to do
some equally odd things to make my splice() code work!

	Noel

[TUHS] origins of void*

[Steve Johnson]

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

Ok, here's my memory of void *, blurred as it may be by time.

Void was put into C, but it was actually not necessary by itself --
the default return type was int, and if nobody was using the value
there was no particular reason to use it.  So only those who were
practitioners of the strong-type religion tended to use it.  A major
problem in making C strongly typed was deciding on a return type for
malloc.  It had traditionally returned char *, but this would require
a cast to allow you to allocate things other than characters.

I was at a /usr/grp conference at the alcohol-fueled reception talking
to Charlie Roberts about the problems of making C more strongly
typed.  The topic of malloc came up.  All of a sudden Charlie got a
huge grin on his face and said "Hey!  Why don't we have malloc return
void *".   It took me a minute or two to even understand what void *
could possibly mean, but the idea was an instant winner.   I seem to
recall it was done a week or two later.   The idea may have simply
ready to be born and others may have had it as well, but this is what
I remember of it.  And the experience sticks in my mind as being an
almost literal example of being "struck by an idea".

Steve

----- Original Message -----
From: "jnc@mercury.lcs.mit.edu (Noel" <Chiappa)>
To:<tuhs at minnie.tuhs.org>
Cc:<jnc at mercury.lcs.mit.edu>
Sent:Sun, 5 Nov 2017 10:43:06 -0500 (EST)
Subject:Re: [TUHS] origins of void*

 > From: Clem Cole

 > typing hard started to become more important in the kernel.

 I can imagine! The V6 kernel had all sorts of, ah, 'unusual' typing -
as I
 learned to my cost when I did that hack version of 'splice()' (to
allow a
 process in a pipline to drop out, and join the two pipes together
directly),
 which I did in V6 (my familiar kernel haunt).

 Since a lot of code does pointer math to generate wait 'channel'
numbers,
 e.g.:

 sleep(ip+2, PPIPE);

 when I naively (out of habit) tried to declare my pointers to be the
correct
 type, the math didn't work any more! ('ip', in this particular case,
was
 declared to be an 'int *'.)

 No doubt part of this was inherited from older versions (of the
system, and
 C); the code was working, and there was no call to tweak it. The lack
of
 casts/coercion in the V6 C compiler may have been an issue, too - I
had to do
 some equally odd things to make my splice() code work!

 Noel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/dbf7817c/attachment.html>

[TUHS] origins of void*

[Paul Ruizendaal]

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


I’m trying to understand the origins of void pointers in C. I think they first appeared formally in the C89 spec, but may have existed in earlier compilers.

Of course, as late as V7 there wasn’t much enforcement of types and hence no need for the void* concept and automatic casting. I suppose ‘lint’ would have flagged it though.

In the 4BSD era there was caddr_t, which I think was used for pretty much the same purposes. Did ‘lint’ in the 4BSD era complain about omitted casts to and fro’ caddr_t?

Background to my question is research into the evolution of the socket API in 4.1x BSD and the persistence of ‘struct sockaddr *’ in actual code, even though the design papers show an intent for ‘caddr_t’ (presumably with ‘void*’ semantics, but I’m not sure).

Paul

[TUHS] origins of void*

[Clem Cole]

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

Funny you should ask.  Im at a conference with Steve Bourne.  He brought up
this topic in a fireside chat tonight.  Steve claims around 1977/78, he had
started to bug Dennis about creating the void type which Bourne wanted for
the Algol68 implementation and was originally rejected by dmr.

BuT when he finally showed Dennis that adding it saved an instruction in
the C return by allowing the void type for function returns, the void type
was added to the language.  Once the type was created it was quickly
realized as useful as typing hard started to become more important in the
kernel.

On Sat, Nov 4, 2017 at 3:23 AM Paul Ruizendaal <pnr at planet.nl> wrote:

>
> I’m trying to understand the origins of void pointers in C. I think they
> first appeared formally in the C89 spec, but may have existed in earlier
> compilers.
>
> Of course, as late as V7 there wasn’t much enforcement of types and hence
> no need for the void* concept and automatic casting. I suppose ‘lint’ would
> have flagged it though.
>
> In the 4BSD era there was caddr_t, which I think was used for pretty much
> the same purposes. Did ‘lint’ in the 4BSD era complain about omitted casts
> to and fro’ caddr_t?
>
> Background to my question is research into the evolution of the socket API
> in 4.1x BSD and the persistence of ‘struct sockaddr *’ in actual code, even
> though the design papers show an intent for ‘caddr_t’ (presumably with
> ‘void*’ semantics, but I’m not sure).
>
> Paul
>
> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/cbb7f2de/attachment.html>

[TUHS] origins of void*

[arnold]

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

Paul Ruizendaal <pnr at planet.nl> wrote:

> I’m trying to understand the origins of void pointers in C. I think
> they first appeared formally in the C89 spec, but may have existed in
> earlier compilers.

void was added after the publication of the first edition of K&R, in
the V7 time frame. The 4.x compilers had support for void pointers and
functions returning void. Also added around the same time was structure
assignment and the ability to pass and return structs by value (although
this was little used).

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

HTH,

Arnold

[TUHS] origins of void*

[Ron Natalie]

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

Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*. 

Sent from my iPhone

> On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
> 
> Paul Ruizendaal <pnr at planet.nl> wrote:
> 
>> I’m trying to understand the origins of void pointers in C. I think
>> they first appeared formally in the C89 spec, but may have existed in
>> earlier compilers.
> 
> void was added after the publication of the first edition of K&R, in
> the V7 time frame. The 4.x compilers had support for void pointers and
> functions returning void. Also added around the same time was structure
> assignment and the ability to pass and return structs by value (although
> this was little used).
> 
>> 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.
> 
> HTH,
> 
> Arnold

[TUHS] origins of void*

[Warner Losh]

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

void functions certainly were much more widely used before void *, but void
* worked on all the compilers I ever used. I'm a relative newcomer, though,
since the first C compiler I used was on a VAX running 4.2BSD...

Warner

On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:

> Yes.  Correct me if I’m wrong, but I recall functions returning void came
> before void*.
>
> Sent from my iPhone
>
> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
> >
> > Paul Ruizendaal <pnr at planet.nl> wrote:
> >
> >> I’m trying to understand the origins of void pointers in C. I think
> >> they first appeared formally in the C89 spec, but may have existed in
> >> earlier compilers.
> >
> > void was added after the publication of the first edition of K&R, in
> > the V7 time frame. The 4.x compilers had support for void pointers and
> > functions returning void. Also added around the same time was structure
> > assignment and the ability to pass and return structs by value (although
> > this was little used).
> >
> >> 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.
> >
> > HTH,
> >
> > Arnold
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/c922b571/attachment-0001.html>

[TUHS] origins of void*

[Clem cole]

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

Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    

FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 

As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  



Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
> 
> Warner
> 
>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>> 
>> Sent from my iPhone
>> 
>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>> >
>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>> >
>> >> I’m trying to understand the origins of void pointers in C. I think
>> >> they first appeared formally in the C89 spec, but may have existed in
>> >> earlier compilers.
>> >
>> > void was added after the publication of the first edition of K&R, in
>> > the V7 time frame. The 4.x compilers had support for void pointers and
>> > functions returning void. Also added around the same time was structure
>> > assignment and the ability to pass and return structs by value (although
>> > this was little used).
>> >
>> >> 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.
>> >
>> > HTH,
>> >
>> > Arnold
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/be93440f/attachment.html>

[TUHS] origins of void*

[Steve Simon]

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

I started out on Edition 7, this was
the interdata / perkin elmer port of v7 (based on Richard Milker’s work at Wollongong with some bits of 2.4BSD added in (csh and vi i remember).

i remember this having a modified v6 compiler which had the shared namespace fir all structure members (hence the stat.st_mtime and friends). but it also had structure assignment and enums.

anyone know where this fits into the compiler evolution, or was it an evolutionary dead end?

-Steve
 

> On 5 Nov 2017, at 17:53, Clem cole <clemc at ccc.com> wrote:
> 
> Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    
> 
> FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 
> 
> As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  
> 
> 
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
>> 
>> Warner
>> 
>>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>>> 
>>> Sent from my iPhone
>>> 
>>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>>> >
>>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>>> >
>>> >> I’m trying to understand the origins of void pointers in C. I think
>>> >> they first appeared formally in the C89 spec, but may have existed in
>>> >> earlier compilers.
>>> >
>>> > void was added after the publication of the first edition of K&R, in
>>> > the V7 time frame. The 4.x compilers had support for void pointers and
>>> > functions returning void. Also added around the same time was structure
>>> > assignment and the ability to pass and return structs by value (although
>>> > this was little used).
>>> >
>>> >> 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.
>>> >
>>> > HTH,
>>> >
>>> > Arnold
>>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/c7e07632/attachment-0001.html>

[TUHS] origins of void*

[Clem cole]

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

That sounds like the Ritchie V7 compiler or the Typersetter C from featured although since it was for the PE target could, I suspect it have been based on Steve’s by then.   

Any idea where the backend came from?  Was it from BTL or was it a different code generator?   I didn’t think much of the PE work left research but I don’t know for sure.  IIRC Leffler and Shannon had something for a compiler backend at Case when they started their PE port, although they had to do some hacking as the model they had was different from any previous PE (they had to deal with a number of 7 bit and 24 bit issues). I believe one of the attractions to the PE was they model the Research folks had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with what they started.

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 10:29 AM, Steve Simon <steve at quintile.net> wrote:
> 
> I started out on Edition 7, this was
> the interdata / perkin elmer port of v7 (based on Richard Milker’s work at Wollongong with some bits of 2.4BSD added in (csh and vi i remember).
> 
> i remember this having a modified v6 compiler which had the shared namespace fir all structure members (hence the stat.st_mtime and friends). but it also had structure assignment and enums.
> 
> anyone know where this fits into the compiler evolution, or was it an evolutionary dead end?
> 
> -Steve
>  
> 
>> On 5 Nov 2017, at 17:53, Clem cole <clemc at ccc.com> wrote:
>> 
>> Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    
>> 
>> FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 
>> 
>> As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  
>> 
>> 
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>>> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
>>> 
>>> Warner
>>> 
>>>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>>>> >
>>>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>>>> >
>>>> >> I’m trying to understand the origins of void pointers in C. I think
>>>> >> they first appeared formally in the C89 spec, but may have existed in
>>>> >> earlier compilers.
>>>> >
>>>> > void was added after the publication of the first edition of K&R, in
>>>> > the V7 time frame. The 4.x compilers had support for void pointers and
>>>> > functions returning void. Also added around the same time was structure
>>>> > assignment and the ability to pass and return structs by value (although
>>>> > this was little used).
>>>> >
>>>> >> 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.
>>>> >
>>>> > HTH,
>>>> >
>>>> > Arnold
>>>> 
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/433d3c56/attachment-0001.html>

[TUHS] origins of void*

[Chet Ramey]

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

On 11/5/17 3:12 PM, Clem cole wrote:

> IIRC Leffler and Shannon had something
> for a compiler backend at Case when they started their PE port, although
> they had to do some hacking as the model they had was different from any
> previous PE (they had to deal with a number of 7 bit and 24 bit issues). I
> believe one of the attractions to the PE was they model the Research folks
> had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with
> what they started.

It was a Harris /6 (I don't know how much that has in common with any PE
model), Sam started with Johnson's PCC, and it was apparently a huge PITA.
I have a copy of his thesis describing the work.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] origins of void*

[Clem cole]

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

Thank you. Now that you mention it. I agree. I had forgotten and confused the Harris and PE

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 1:08 PM, Chet Ramey <chet.ramey at case.edu> wrote:
> 
>> On 11/5/17 3:12 PM, Clem cole wrote:
>> 
>> IIRC Leffler and Shannon had something
>> for a compiler backend at Case when they started their PE port, although
>> they had to do some hacking as the model they had was different from any
>> previous PE (they had to deal with a number of 7 bit and 24 bit issues). I
>> believe one of the attractions to the PE was they model the Research folks
>> had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with
>> what they started.
> 
> It was a Harris /6 (I don't know how much that has in common with any PE
> model), Sam started with Johnson's PCC, and it was apparently a huge PITA.
> I have a copy of his thesis describing the work.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>         ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] origins of void*

[Steve Simon]

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

Hi,

Thinking about it some more,  the compiler and linker only checked the first 7 or 8 characters - so I had to use hash8 (comp.sources.unix I think) to port JOVE.

It also didn’t support a dynamically growing stack segment, so you had to use setstack(1) if you had an aggressively recursive code, the though I assume this was a kernel or hardware limitation rather than a compiler feature.

-Steve


> On 5 Nov 2017, at 20:12, Clem cole <clemc at ccc.com> wrote:
> 
> That sounds like the Ritchie V7 compiler or the Typersetter C from featured although since it was for the PE target could, I suspect it have been based on Steve’s by then.   
> 
> Any idea where the backend came from?  Was it from BTL or was it a different code generator?   I didn’t think much of the PE work left research but I don’t know for sure.  IIRC Leffler and Shannon had something for a compiler backend at Case when they started their PE port, although they had to do some hacking as the model they had was different from any previous PE (they had to deal with a number of 7 bit and 24 bit issues). I believe one of the attractions to the PE was they model the Research folks had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with what they started.
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
> On Nov 5, 2017, at 10:29 AM, Steve Simon <steve at quintile.net> wrote:
> 
>> I started out on Edition 7, this was
>> the interdata / perkin elmer port of v7 (based on Richard Milker’s work at Wollongong with some bits of 2.4BSD added in (csh and vi i remember).
>> 
>> i remember this having a modified v6 compiler which had the shared namespace fir all structure members (hence the stat.st_mtime and friends). but it also had structure assignment and enums.
>> 
>> anyone know where this fits into the compiler evolution, or was it an evolutionary dead end?
>> 
>> -Steve
>>  
>> 
>> On 5 Nov 2017, at 17:53, Clem cole <clemc at ccc.com> wrote:
>> 
>>> Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    
>>> 
>>> FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 
>>> 
>>> As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  
>>> 
>>> 
>>> 
>>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>>> 
>>> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>>> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
>>>> 
>>>> Warner
>>>> 
>>>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>>>> >
>>>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>>>> >
>>>> >> I’m trying to understand the origins of void pointers in C. I think
>>>> >> they first appeared formally in the C89 spec, but may have existed in
>>>> >> earlier compilers.
>>>> >
>>>> > void was added after the publication of the first edition of K&R, in
>>>> > the V7 time frame. The 4.x compilers had support for void pointers and
>>>> > functions returning void. Also added around the same time was structure
>>>> > assignment and the ability to pass and return structs by value (although
>>>> > this was little used).
>>>> >
>>>> >> 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.
>>>> >
>>>> > HTH,
>>>> >
>>>> > Arnold
>>>> 
>>>> 

[TUHS] origins of void*

[Paul Ruizendaal]

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

Many thanks all for the replies, most enlightening.

I’ve examined the compiler sources for recognising ‘void’ as a keyword in the lexer, as far as available on the TUHS Unix Tree web pages.

For the PDP11 with pcc the results are that void is not present in V7, but is in SysIII. That is consistent with it being first implemented in 1979 on Unix/TS, and just missing the V7 release. As to the Ritchie compiler, void only first appears in SysV in 1983 (it is not in 2.9BSD). For the VAX it is not in 32V and 3BSD, but it is in 4BSD.

So it would seem that void pointers were available to the wider world (including BSD) from the summer of 1980 onwards.

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

In 4.1x BSD the definition of caddr_t remains 'char *', not 'void *’. Was there a special reason for that, or was that simply inertia from what it was in the V7 source?

Paul

[TUHS] origins of void*

[Warner Losh]

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

On Nov 5, 2017 1:44 PM, "Paul Ruizendaal" <pnr at planet.nl> wrote:

Many thanks all for the replies, most enlightening.

I’ve examined the compiler sources for recognising ‘void’ as a keyword in
the lexer, as far as available on the TUHS Unix Tree web pages.

For the PDP11 with pcc the results are that void is not present in V7, but
is in SysIII. That is consistent with it being first implemented in 1979 on
Unix/TS, and just missing the V7 release. As to the Ritchie compiler, void
only first appears in SysV in 1983 (it is not in 2.9BSD). For the VAX it is
not in 32V and 3BSD, but it is in 4BSD.

So it would seem that void pointers were available to the wider world
(including BSD) from the summer of 1980 onwards.

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

In 4.1x BSD the definition of caddr_t remains 'char *', not 'void *’. Was
there a special reason for that, or was that simply inertia from what it
was in the V7 source?



It is still is defined like that in FreeBSD. So p + 5 works. It doesn't for
void *, except as a gcc extension.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/11e835a3/attachment.html>

[TUHS] origins of void*

[arnold]

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

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.

This is my take on it, anyway. :-)

HTH,

Arnold

[TUHS] origins of void*

[Warner Losh]

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

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/67775e3c/attachment.html>