[TUHS] reviving a bit of WWB

[Clem Cole]

Right .. I remember running into/using that idiom in a couple of places in
a few other drivers in the early years.  I also remember working one of the
CAD tools (it may have been one of the UCB CAD editors) which were very
graphics centric and running into it there.

I always looked at this as part of the original C heritage from simpler
times *i.e.* from ESPOL/BCPL/B and the like, when it was still considered a
'low level' language that mapped well to the HW at hand.  As the more and
more features got added, the focus of the language changed ... ney
Chisnall's 2018 screed: C is not a low level language
<https://queue.acm.org/detail.cfm?id=3212479>   Not nearly as bad as the
pile we got with 'modern' C++ [which I'm loath to use].

Clem

On Mon, Sep 21, 2020 at 5:23 PM Rob Pike <robpike at gmail.com> wrote:

> Back when we were running v5 at the University of Toronto, we had a
> graphics device that we accessed, on our split I&D space 11/45, using 0,
> something like this:
>
> struct x {
>    int reg0, reg1, ...;
> };
>
> 0->reg1 = 0234;
>
> Several old details of old C made this possible as well: Struct tags were
> global, -> worked on any pointer, and ints and pointers were
> interchangeable.
>
> -rob
>
>
> On Tue, Sep 22, 2020 at 6:51 AM John Cowan <cowan at ccil.org> wrote:
>
>>
>>
>> On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki at buric.co> wrote:
>>
>>
>>> I've never written anything that uses varargs, so I've never run into
>>> that.  But I've actually done quite a bit of work with an environment
>>> where this isn't true: MS-DOS using the large or huge model.  In this
>>> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
>>> conformant to pass an int variable as an argument where a pointer variable
>>> is expected.
>>>
>>
>> If the compiler was ISO-conformant (which it almost certainly was not),
>> that would not matter.  0 in int context would be a 2-byte int with all
>> bits zero, and 0 in pointer context would be a 4-byte null pointer,
>> probably with all bits zero.
>>
>> C doesn't require that the address represented by the null pointer
>> (whether or not it is all-bits-zero) is inaccessible, merely that there is
>> no C object or function there.  A simple shim of the appropriate size (1,
>> 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200921/d36b57fc/attachment.htm>