Yes. Correct me if I’m wrong, but I recall functions returning void came before void*. Sent from my iPhone code.

On 5 Nov 2017, at 17:53, Clem cole <clemc(a)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(a)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(a)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(a)skeeve.com wrote: >> > >> > Paul Ruizendaal <pnr(a)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 >> >

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.

On 5 Nov 2017, at 20:12, Clem cole <clemc(a)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(a)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(a)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(a)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(a)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(a)skeeve.com wrote: >>> > >>> > Paul Ruizendaal <pnr(a)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 >>> >>>

Only for kernel code. I am pretty sure caddr_t wasn't used in user-land

Paul Ruizendaal <pnr(a)planet.nl> wrote: user-land code. 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 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!

Steve ----- Original Message ----- From: "Warner Losh" <imp(a)bsdimp.com> To: <arnold(a)skeeve.com> Cc: "TUHS main list" <tuhs(a)minnie.tuhs.org>, "Paul Ruizendaal" <pnr(a)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(a)skeeve.com> wrote: 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

I believe one of C’s biggest failings is that they did not solve the schizophrenic definition of char*. Char* as historically implemented and then  CODIFIED in the C and C++ standards is both the basic character type as well as the smallest addressable unit of storage. Thiswas all peachy keen in the 8 bit ASCII days (and even earlier alternative character sets such as EBCDIC, and its predecessors and other historical character sets like UNIVAC’s fielddata_), but fell apart when we started into the 16 bit and larger UNICODE._ __ _We needed a basic memory type that had sizeof == 1 (which void*) did not meet and release char from having to play double duty._ __ __ __

On Nov 6, 2017, at 4:25 PM, Ron Natalie <ron(a)ronnatalie.com> wrote: I believe one of C’s biggest failings is that they did not solve the schizophrenic definition of char*. Char* as historically implemented and then CODIFIED in the C and C++ standards is both the basic character type as well as the smallest addressable unit of storage. This was all peachy keen in the 8 bit ASCII days (and even earlier alternative character sets such as EBCDIC, and its predecessors and other historical character sets like UNIVAC’s fielddata), but fell apart when we started into the 16 bit and larger UNICODE. We needed a basic memory type that had sizeof == 1 (which void*) did not meet and release char from having to play double duty.

void* serves a different purpose. It says this is an untyped pointer (or a ptr to an instance of any type) so no question of size being an issue.

It shouldn't even have been "void*". I would've preferred _* and _ instead of void* and void. Much more appropriate for a concise language like C!

On 8 Nov 2017, at 20:56, Ron Natalie <ron(a)ronnatalie.com> wrote: Ralph is right. You don't have to go any further than the old x86 implementations to find machines where the function pointers are bigger than the data pointers. Further void* both by the standard and by practical matter MUST have the format of char*. Any other type of pointer has to be convertible to void*/char* (as both must address the smallest addressable unit). Most machines, don't need to actually do any pointer conversion but more than a few do, mostly those that have word addressing as native. If I recall properly, the CRAY, which didn't really have byte addressing at all, natively, just had the byte offset into word encoded in high order bits. The UNIVAC has a quite rich "partial word" format encoded in the pointers. The HEP as well used the low order bits to switch the operand size as well as the offset into the word. This all works because conversion via normal means converted the from or to the void*/char* and whatever the other data pointer type, as it knows the type of both sides of the conversion. The BSD kernels however were ripe with what I call "conversion by union." It would store one pointer type into a union of one pointer type and retrieve it from another. Now this is officially undefined behavior (as is most use of sockaddr_t in the early days). I remember spending a few days running around the kernel "fixing" this when doing the HEP port.

I don’t care what they say. 36-bits is here to stay!

The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement a C compiler on that hardware? https://stackoverflow.com/questions/3153141/defining-a-byte-in-c <https://stackoverflow.com/questions/3153141/defining-a-byte-in-c> https://en.wikipedia.org/wiki/36-bit <https://en.wikipedia.org/wiki/36-bit> As DIGEX teased the VAX weenies at DECUS: “If you’re not playing with 36 bits, you’re not playing with a full DEC!" -Don

On 8 Nov 2017, at 20:56, Ron Natalie &lt;ron(a)ronnatalie.com&gt; wrote: Ralph is right. You don't have to go any further than the old x86 implementations to find machines where the function pointers are bigger than the data pointers. Further void* both by the standard and by practical matter MUST have the format of char*. Any other type of pointer has to be convertible to void*/char* (as both must address the smallest addressable unit). Most machines, don't need to actually do any pointer conversion but more than a few do, mostly those that have word addressing as native. If I recall properly, the CRAY, which didn't really have byte addressing at all, natively, just had the byte offset into word encoded in high order bits. The UNIVAC has a quite rich "partial word" format encoded in the pointers. The HEP as well used the low order bits to switch the operand size as well as the offset into the word. This all works because conversion via normal means converted the from or to the void*/char* and whatever the other data pointer type, as it knows the type of both sides of the conversion. The BSD kernels however were ripe with what I call "conversion by union." It would store one pointer type into a union of one pointer type and retrieve it from another. Now this is officially undefined behavior (as is most use of sockaddr_t in the early days). I remember spending a few days running around the kernel "fixing" this when doing the HEP port. Ah, yes, the strict alias rule. Took FreeBSD, at least, about a decade to

The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement a C compiler on that hardware?

Ralph is right. You don't have to go any further than the old x86 implementations to find machines where the function pointers are bigger than the data pointers.

I agree that `char' shouldn't do double duty as the smallest addressable unit and I was suggesing uint8_t does that job.

1 bit bytes, the smallest addressable unit on the PDP-10, sounds kinda cool actually. Now would those be signed or unsigned?

It's funny you should mention "1-bit bytes" and PowerPC close together, because the PowerPC has an architectural feature that I have not seen discussed much - the 8 x 4 bit CR register set [...] and of course the usual branch tests. I have been curious about whether a compiler could make good use of this facility.