[TUHS] origins of void*

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

[TUHS] origins of void* -- Apology!

[Steve Johnson]

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

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 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 [1]>
 wrote:
Paul Ruizendaal <pnr at planet.nl [2]> 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 

 

Links:
------
[1] mailto:arnold at skeeve.com
[2] mailto:pnr at planet.nl

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

[TUHS] origins of void* -- Apology!

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

[TUHS] origins of void* -- Apology!

[Ron Natalie]

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

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.

 

 

 

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

[TUHS] origins of void* -- Apology!

[Arthur Krewat]

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

char (at least these days) is signed. So really, it's 7-bit ASCII.

I've been bitten by the 7-bit ASCII thing when it comes to modern 
character sets. unsigned char gets tiresome ;)


On 11/6/2017 7:25 PM, Ron Natalie 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.
>
> 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._
>
> __
>
> __
>
> __
>

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

[TUHS] origins of void* -- Apology!

[Ron Natalie]

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

It’s worse than that.   “char” is defined as neither signed nor unsigned.   The signedness is implementation defined.    This was why we have the inane “signed” keyword.

 

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Arthur Krewat
Sent: Monday, November 6, 2017 7:35 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] origins of void* -- Apology!

 

char (at least these days) is signed. So really, it's 7-bit ASCII.

I've been bitten by the 7-bit ASCII thing when it comes to modern character sets. unsigned char gets tiresome ;)



On 11/6/2017 7:25 PM, Ron Natalie 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.

 

 

 

 

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

[TUHS] origins of void* -- Apology!

[Bakul Shah]

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



> On Nov 6, 2017, at 4:25 PM, Ron Natalie <ron at 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.

C has had uint8_t since C99.

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!

[TUHS] origins of void* -- Apology!

[Ron Natalie]

> C has had uint8_t since C99.

uint8_t isn't the same thing as I was proposing.

[TUHS] origins of void* -- Apology!

[Ralph Corderoy]

Hi Bakul,

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

In C, ignoring POSIX, a void pointer is big enough to hold any pointer
to data.  Pointers to data may be different sizes.  And a void pointer
can't hold a function pointer, but all function pointers are defined to
be the same size.  Thus `void (*)(void)' can be used as a generic
function pointer type and cast to other ones when needed.

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

That's awful.  Might as well say `return' occurs so often, it should
have been `@'.  :-)

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] origins of void* -- Apology!

[Ron Natalie]

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.



-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Ralph Corderoy
Sent: Wednesday, November 8, 2017 12:45 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] origins of void* -- Apology!

Hi Bakul,

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

In C, ignoring POSIX, a void pointer is big enough to hold any pointer to data.  Pointers to data may be different sizes.  And a void pointer can't hold a function pointer, but all function pointers are defined to be the same size.  Thus `void (*)(void)' can be used as a generic function pointer type and cast to other ones when needed.

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

That's awful.  Might as well say `return' occurs so often, it should have been `@'.  :-)

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] origins of void* -- Apology!

[Don Hopkins]

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


> On 8 Nov 2017, at 20:56, Ron Natalie <ron at 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.

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

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

[TUHS] origins of void* -- Apology!

[Ron Natalie]

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

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

 

I don’t recall a DEC 10 (or PDP-6) C compiler, but such certainly did exist on the UNIVAC 1100 which had a similar arbitrary partial word format.

The Univac never could decide what the character set was, be it ASCII (in 7, 8, or 9 bits) or FIELDDATA (six bits).

 

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

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

[TUHS] origins of void* -- Apology!

[Don Hopkins]

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


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

You know what they say: 64 bits is just 36 bits at 2.88% interest compounded monthly for two years! 

-Don

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

[TUHS] origins of void* -- Apology!

[Don Hopkins]

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


> On 8 Nov 2017, at 21:47, Don Hopkins <SimHacker at gmail.com> wrote:
> 
> 
>> I don’t care what they say.
>> 36-bits is here to stay!
> 
> You know what they say: 64 bits is just 36 bits at 2.88% interest compounded monthly for two years! 
> 
> -Don
> 

That’s not what they say: it’s actually twenty years! ;) 

-Don

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

[TUHS] origins of void* -- Apology!

[Don Hopkins]

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

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


Re: PDP-10 backend for gcc
https://gcc.gnu.org/ml/gcc/2000-09/msg00073.html <https://gcc.gnu.org/ml/gcc/2000-09/msg00073.html>

ftp://kermit.columbia.edu/kermit/dec20/assembler-guide.txt <ftp://kermit.columbia.edu/kermit/dec20/assembler-guide.txt>
2.12. Byte Instructions

In the PDP-10 a "byte" is some number of contiguous bits within one word.  A
byte pointer is a word that describes the byte.  There are three parts to the
description of a byte: the word (i.e., address) in which the byte occurs, the
position of the byte within the word, and the length of the byte.

A byte pointer has the following format:


   Bit     000000 000011 1 1 1111 112222222222333333
 Position  012345 678901 2 3 4567 890123456789012345
           _________________________________________
          |      |      | | |    |                  |
          | POS  | SIZE |U|I| X  |        Y         |
          |______|______|_|_|____|__________________|

   - POS is the byte position: the number of bits remaining in the word
     to the right of the byte.

   - SIZE is the byte size in bits.

   - The U field is reserved for future use and must be zero.

   - I, X, and Y are the same as in an instruction.

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

[TUHS] origins of void* -- Apology!

[Clem Cole]

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

On Wed, Nov 8, 2017 at 8:39 PM, Don Hopkins <don at donhopkins.com> wrote:

>
>
> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement
> a C compiler on that hardware?
>
> ​Yes:  There were at least 2 that I knew about:
https://github.com/PDP-10​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/7e7ca560/attachment.html>

[TUHS] origins of void* -- Apology!

[Warner Losh]

On Wed, Nov 8, 2017 at 1:39 PM, Don Hopkins <don at donhopkins.com> wrote:

>
> On 8 Nov 2017, at 20:56, Ron Natalie <ron at 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.
>
> Ah, yes, the strict alias rule. Took FreeBSD, at least, about a decade to
excise it from the tree...


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

Yes. Several people did. We had a thread about it not to long ago. kcc Kok
Chen's C compiler for PDP-10 can be found at https://github.com/PDP-10/kcc.

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

[TUHS] origins of void* -- Apology!

[Lars Brinkhoff]

Warner Losh wrote:
> Don Hopkins wrote:
>> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever
>> implement a C compiler on that hardware?
>
> Yes. Several people did. We had a thread about it not to long ago. kcc Kok
> Chen's C compiler for PDP-10 can be found at https://github.com/PDP-10/kcc.

I know about four:

- C10 by Alan Snyder
- KCC by Kok Chen, improved by Ken Harrenstien
- GCC backend by myself, funded by XKL
- PCC backend by Anders Magnusson

[TUHS] origins of void* -- Apology!

[Steve Nickolas]

On Wed, 8 Nov 2017, Ron Natalie 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.

It could get pretty baroque, depending on your memory model; as you had 
16-bit pointers and 32-bit (actually 20-bit because of the hairy way 
segmentation worked) pointers and what was used for what depended on 
compiler switches or the nonstandard "near" and "far" keywords (e.g., char 
far *screen=0xA0000000;).

-uso.

[TUHS] origins of void* -- Apology!

[Bakul Shah]

On Wed, 08 Nov 2017 17:44:50 +0000 Ralph Corderoy <ralph at inputplus.co.uk> wrote:
Ralph Corderoy writes:
> Hi Bakul,
> 
> > 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.
> 
> In C, ignoring POSIX, a void pointer is big enough to hold any pointer
> to data.  Pointers to data may be different sizes.  And a void pointer
> can't hold a function pointer, but all function pointers are defined to
> be the same size.  Thus `void (*)(void)' can be used as a generic
> function pointer type and cast to other ones when needed.

Yes, I was being sloppy, not mentiong the fn ptr exception.

I was saying `void *' represents a generic non-function
pointer. I was just separating it from what Ron wants, which
is, if I understand right, is a pointer to the *smallest*
addressable memory unit. I agree that `char' shouldn't do
double duty as the smallest addressable unit and I was
suggesing uint8_t does that job. But that is not true either.
There are word addressable machines where you can't directly
address bytes (if they have 8 bit bytes). Nor would you want a
"byte pointer" to be a general pointer.

> > 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!
> 
> That's awful.  Might as well say `return' occurs so often, it should
> have been `@'.  :-)

Fits right in with "e1 ? e2 : e3" :-) My thinking was that the
word void loses any meaning in "void *". It is a not a pointer
to an empty space.  Seems people just didn't want to add a new
keyword so they reused void. _ is alreast more mnemonic.

[TUHS] origins of void* -- Apology!

[Lars Brinkhoff]

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

There are still machines around where 8-bit bytes isn't a natural fit.

[TUHS] origins of void* -- Apology!

[Don Hopkins]

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


> On 9 Nov 2017, at 07:37, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Bakul Shah wrote:
>> I agree that `char' shouldn't do double duty as the smallest
>> addressable unit and I was suggesing uint8_t does that job.
> 
> There are still machines around where 8-bit bytes isn't a natural fit.

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

The PowerPC was great at smashing and swizzling bit fields and emulating other CPU instruction sets with different memory layouts, because it could rotate and mask very quickly! You could do byte reversal in three instructions: "rotate left" 8 to position two of the bytes, then two “rotate left word immediate then mask insert” instructions. 

https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.alangref/idalangref_32bit_rtate_shift.htm <https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.alangref/idalangref_32bit_rtate_shift.htm>

http://sametwice.com/rlwinm <http://sametwice.com/rlwinm>

https://www.google.com/patents/US20140208067 <https://www.google.com/patents/US20140208067>

PowerPC AltiVec was a really beautiful instruction set.

https://en.wikipedia.org/wiki/AltiVec <https://en.wikipedia.org/wiki/AltiVec>

-Don

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

[TUHS] origins of void* -- Apology!

[Lars Brinkhoff]

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

There are only instructions to load unsigned bytes.  No sign extensions.

But sadly, this is getting off topic.

[TUHS] PowerPC, bit twiddling - was Re: origins of void* -- Apology!

[Toby Thain]

On 2017-11-09 2:14 AM, Don Hopkins wrote:
> 
>> On 9 Nov 2017, at 07:37, Lars Brinkhoff <lars at nocrew.org
>> <mailto:lars at nocrew.org>> wrote:
>>
>> Bakul Shah wrote:
>>> I agree that `char' shouldn't do double duty as the smallest
>>> addressable unit and I was suggesing uint8_t does that job.
>>
>> There are still machines around where 8-bit bytes isn't a natural fit.
> 
> 1 bit bytes, the smallest addressable unit on the PDP-10, sounds kinda
> cool actually. Now would those be signed or unsigned?
> 
> The PowerPC was great at smashing and swizzling bit fields ...

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 the Conditional
Register Logical instructions that can operate on them directly as if
they were 32 single bit registers, with operations AND, OR, XOR, NAND,
NOR, EQV (complemented XOR), AND complemented operand, OR complemented
operand, move between 4-bit fields, and of course the usual branch tests.

I have been curious about whether a compiler could make good use of this
facility.

--Toby




> 
> -Don
> 

[TUHS] PowerPC, bit twiddling - was Re: origins of void* -- Apology!

[Ralph Corderoy]

Hi Toby,

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

POWER, PowerPC's predecessor, had this too, at least on the IBM RS/6000s
running AIX I used.  A lot of the work was performance related, so I
spent much time looking at disassembly of the output of xlc, their cc.
It seemed to make use of more than one CR quite often, but never very
many of them.  I recall thinking it could have done better.  Certainly,
re-doing bits in assembler allowed that to be exploited as long as one
could track which CR was tracking what previous test and whether it was
still valid.  Perhaps the compiler's architecture, probably not written
from scratch?, didn't adapt well to that possibility?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] origins of void* -- Apology!

[Nelson H. F. Beebe]

Arthur Krewat <krewat at kilonet.net> writes on Mon, 6 Nov 2017 19:34:34 -0500

>> char (at least these days) is signed. So really, it's 7-bit ASCII.

I decided last night to investigate that statement, and updated my
C/C++ features tool to test the sign and range of char and wchar_t.  

I ran it in our test lab with physical and virtual machines
representing many different GNU/Hurd, GNU/Linux, *BSD, macOS, Minix,
Solaris, and other Unix family members, on ARM, MIPS, PowerPC, SPARC,
x86, and x86-64 CPU architectures.  Here is a summary:

	% cat *.log | grep '^ char type is' | sort | uniq -c
	    157         char type is          signed
	      3         char type is          unsigned

The sole outliers are 

	* Arch Linux ARM on armv7l
	* IBM CentOS Linux release 7.4.1708 on PowerPC-8
	* SGI IRIX 6.5 on MIPS R10000-SC

for which I found these log data:

	Character range and sign...
		CHAR_MIN                        =   +0
		CHAR_MAX                        = +255
		SCHAR_MIN                       = -128
		SCHAR_MAX                       = +127
		UCHAR_MAX                       = +255
		char type is          unsigned
		signed char type is   signed
		unsigned char type is unsigned

The last two lines are expected, but my program checked for an
incorrect result, and would have produced the string "WRONG!" in the
output; no system had that result.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] origins of void* -- Apology!

[Tony Finch]

Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>
> 	% cat *.log | grep '^ char type is' | sort | uniq -c
> 	    157         char type is          signed
> 	      3         char type is          unsigned
>
> The sole outliers are
>
> 	* Arch Linux ARM on armv7l
> 	* IBM CentOS Linux release 7.4.1708 on PowerPC-8
> 	* SGI IRIX 6.5 on MIPS R10000-SC

Nice survey, thanks!

I learned C using the Norcroft C compiler on early Acorn / ARM machines
where char was unsigned. That is still the case, though ARM have switched
from Norcroft to clang.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0774h/kpr1493281322162.html

(And I started learning about unix from reading articles about RISC iX,
Acorn's 4.3BSD port to the Archimedes.)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Tyne, Dogger: Variable 3 or 4, becoming west or southwest 5 to 7, perhaps gale
8 later in north. Slight, becoming moderate. Occasional rain later. Good,
occasionally moderate.

[TUHS] origins of void* -- Apology!

[Otto Moerbeek]

On Wed, Nov 08, 2017 at 12:48:47PM +0000, Tony Finch wrote:

> Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> >
> > 	% cat *.log | grep '^ char type is' | sort | uniq -c
> > 	    157         char type is          signed
> > 	      3         char type is          unsigned
> >
> > The sole outliers are
> >
> > 	* Arch Linux ARM on armv7l
> > 	* IBM CentOS Linux release 7.4.1708 on PowerPC-8
> > 	* SGI IRIX 6.5 on MIPS R10000-SC
> 
> Nice survey, thanks!
> 
> I learned C using the Norcroft C compiler on early Acorn / ARM machines
> where char was unsigned. That is still the case, though ARM have switched
> from Norcroft to clang.

whether char is signed or unsigned is defined by the ABI of the
platform, not by the compiler (if the compiler builder respects the
ABI, which is of course a wise thing to do).


	-Otto

[TUHS] origins of void* -- Apology!

[Warner Losh]

On Wed, Nov 8, 2017 at 5:48 AM, Tony Finch <dot at dotat.at> wrote:

> Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> >
> >       % cat *.log | grep '^ char type is' | sort | uniq -c
> >           157         char type is          signed
> >             3         char type is          unsigned
> >
> > The sole outliers are
> >
> >       * Arch Linux ARM on armv7l
> >       * IBM CentOS Linux release 7.4.1708 on PowerPC-8
> >       * SGI IRIX 6.5 on MIPS R10000-SC
>
> Nice survey, thanks!
>
> I learned C using the Norcroft C compiler on early Acorn / ARM machines
> where char was unsigned. That is still the case, though ARM have switched
> from Norcroft to clang.
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.
> doc.dui0774h/kpr1493281322162.html
>
> (And I started learning about unix from reading articles about RISC iX,
> Acorn's 4.3BSD port to the Archimedes.)
>

ARM's pre-EABI ABIs dictated that char be unsigned. It's all dictated by
the ABI that's implemented, and less about which compiler is used. Now that
EABI is basically mainstream, unsigned characters on ARM has become a
historic oddity.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/6bf5abe8/attachment.html>

[TUHS] origins of void* -- Apology!

[Nemo]

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

On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com> wrote:
> It’s worse than that.   “char” is defined as neither signed nor unsigned.
> The signedness is implementation defined.    This was why we have the inane
> “signed” keyword.

What was that story about porting an early UNIX to a machine with
different char polarity?  I dimly recall only a few problems.

N.

[TUHS] origins of void* -- Apology!

[Warner Losh]

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

On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224 at gmail.com> wrote:

> On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com> wrote:
> > It’s worse than that.   “char” is defined as neither signed nor unsigned.
> > The signedness is implementation defined.    This was why we have the
> inane
> > “signed” keyword.
>
> What was that story about porting an early UNIX to a machine with
> different char polarity?  I dimly recall only a few problems.
>

Doesn't even have to be very early... There's lots of 'assume char is
signed bugs' in even modern code. So many that ARM gave up on the idea that
unsigned char was good (since the underlying ARM architecture supported it
better) and their modern ABIs are all signed char. The other thing that
EABI fixes is the crazy alignment rules that were out-of-step with the rest
of the computer industry that broke a lot of networking and storage code on
ARM because its rules caused structs that would otherwise describe the
binary layout to be suddenly wrong. Yes, that is an implementation choice,
just a poor one that was eventually corrected.

When I was working on FreeBSD/arm only a decade ago, I'd routinely hit both
of these issues...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/568e164a/attachment.html>

[TUHS] origins of void* -- Apology!

[Ron Natalie]

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

The “story” was the reticence to require something that MIGHT take additional instructions.     Again, this stems from yet another overload of char, that of a small numeric type (many languages do not treat characters as integers).     The idea was to let char be the regular char type and if you were going to do math on it, you’d better explicitly state signed/unsigned, of course, people get sloppy leading to the bugs you noted.

 

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Warner Losh
Sent: Wednesday, November 8, 2017 11:13 AM
To: Nemo
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] origins of void* -- Apology!

 

 

 

On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224 at gmail.com> wrote:

On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com> wrote:
> It’s worse than that.   “char” is defined as neither signed nor unsigned.
> The signedness is implementation defined.    This was why we have the inane
> “signed” keyword.

What was that story about porting an early UNIX to a machine with
different char polarity?  I dimly recall only a few problems.

 

Doesn't even have to be very early... There's lots of 'assume char is signed bugs' in even modern code. So many that ARM gave up on the idea that unsigned char was good (since the underlying ARM architecture supported it better) and their modern ABIs are all signed char. The other thing that EABI fixes is the crazy alignment rules that were out-of-step with the rest of the computer industry that broke a lot of networking and storage code on ARM because its rules caused structs that would otherwise describe the binary layout to be suddenly wrong. Yes, that is an implementation choice, just a poor one that was eventually corrected.

 

When I was working on FreeBSD/arm only a decade ago, I'd routinely hit both of these issues...

 

Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/0a653e9e/attachment-0001.html>

[TUHS] origins of void* -- Apology!

[Steffen Nurpmeso]

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

Warner Losh <imp at bsdimp.com> wrote:
 |On Wed, Nov 8, 2017 at 9:07 AM, Nemo <[1]cym224 at gmail.com[/1]> wrote:
 |On 6 November 2017 at 19:36, Ron Natalie <[2]ron at ronnatalie.com[/2]> wrote:
 |> It’s worse than that.   “char” is defined as neither signed nor unsigned.
 |> The signedness is implementation defined.    This was why we have \
 |> the inane
 |> “signed” keyword.
 ...
 |What was that story about porting an early UNIX to a machine with
 |different char polarity?  I dimly recall only a few problems.
 |
 |Doesn't even have to be very early... There's lots of 'assume char \
 |is signed bugs' in even modern code. So many that ARM gave up on the \
 |idea that 
 |unsigned char was good (since the underlying ARM architecture supported \
 |it better) and their modern ABIs are all signed char. The other thing \
 ..
 |When I was working on FreeBSD/arm only a decade ago, I'd routinely \
 |hit both of these issues...

I had one of those on Debian/arm64 (Bug#806300) no sooner but
November 2015, very friendly reported as

 |This symptom and the pattern of failures is typical of programs that
 |assume that plain char is signed. Fortunately there's a warning in
 |the build log that tells you exactly where the bug is:

(in fact already mentioned in some hidden archlinux forum, and
also to me in private by a Swede, but i failed to see, and forgot,
hu-hu!!, all in March 2015) introduced in December 2013 when
blindly fixing CC warnings (Many: fix gcc 4.8.2 -fstrict-overflow
-Wstrict-overflow=5).  Testing char not int against EOF is bad.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] origins of void* -- Apology!

[Steve Johnson]

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

I don't think either Dennis or I ever thought that characters should
be signed.  It's true that PCC didn't specify it.  It's also true
that in those days the 8th bit in a char was pretty much unused
(except by the shell), so the issue never arose.  I believe the folks
at Bell Labs Holmdel who did the port to the Vax were the first ones
to come up with signed characters.  I think it was a real blot on
C.  For example, consider:
       struct {  ....
              char x:1;
       ...
       }

If characters are signed, the only legal values of x are 0 and -1 (!)

Steve

----- Original Message -----
From:
 "Warner Losh" <imp at bsdimp.com>

To:
"Nemo" <cym224 at gmail.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:
Wed, 8 Nov 2017 09:12:50 -0700
Subject:
Re: [TUHS] origins of void* -- Apology!

On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224 at gmail.com [1]>
 wrote:
On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com [2]>
wrote:
 > It’s worse than that.   “char” is defined as neither signed
nor unsigned.
 > The signedness is implementation defined.    This was why we have
the inane
 > “signed” keyword.

 What was that story about porting an early UNIX to a machine with
 different char polarity?  I dimly recall only a few problems.

Doesn't even have to be very early... There's lots of 'assume char is
signed bugs' in even modern code. So many that ARM gave up on the idea
that unsigned char was good (since the underlying ARM architecture
supported it better) and their modern ABIs are all signed char. The
other thing that EABI fixes is the crazy alignment rules that were
out-of-step with the rest of the computer industry that broke a lot of
networking and storage code on ARM because its rules caused structs
that would otherwise describe the binary layout to be suddenly wrong.
Yes, that is an implementation choice, just a poor one that was
eventually corrected.

When I was working on FreeBSD/arm only a decade ago, I'd routinely hit
both of these issues...

Warner

 

Links:
------
[1] mailto:cym224 at gmail.com
[2] mailto:ron at ronnatalie.com

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