[COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C

[COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C

[Stuff Received]

Moved to COFF.

On 2024-09-20 11:07, Dave Horsfall wrote (in part):
> 
> Giggle...  In a device driver I wrote for V6, I used the expression
> 
>      "0123"[n]
> 
> and the two programmers whom I thought were better than me had to ask me
> what it did...
> 
> -- Dave, brought up on PDP-11 Unix[*]
> 
> [*]
> I still remember the days of BOS/PICK/etc, and I staked my career on Unix.

Working on embedded systems, we often used constructs such as a[-4] to 
either read or modify stuff on the stack (for that particular 
compiler+processor only).

S.

[COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C

[segaloco via COFF]

On Friday, September 20th, 2024 at 8:56 AM, Stuff Received <stuff@riddermarkfarm.ca> wrote:

> Moved to COFF.
> 
> On 2024-09-20 11:07, Dave Horsfall wrote (in part):
> 
> > Giggle... In a device driver I wrote for V6, I used the expression
> > 
> > "0123"[n]
> > 
> > and the two programmers whom I thought were better than me had to ask me
> > what it did...
> > 
> > -- Dave, brought up on PDP-11 Unix[*]
> > 
> > [*]
> > I still remember the days of BOS/PICK/etc, and I staked my career on Unix.
> 
> 
> Working on embedded systems, we often used constructs such as a[-4] to
> either read or modify stuff on the stack (for that particular
> compiler+processor only).
> 
> S.

My takeaway on out of bounds array access is you're taking the wheel in your own hands WRT the memory characteristics of your application.  If you're using some pointer to the middle of a known memory region (e.g. I/O registers) then you're fine stepping a subscript out of bounds in either direction.  If you're making assumptions about how compiler and linker <xyz> are going to map C abstractions into RAM/stack...then you better be prepared for a compiler author to have a different mapping plan in mind.  As John Mashey put it, paraphrasing, C doesn't require you to agonize over all the details of the machine, but it also allows you to get at many of those details if you so choose.

- Matt G.

[COFF] Re: Maximum Array Sizes in 16 bit C

[Aron Insinga]

FWIW, I just saw this in code generated by bison:

     (yyvsp[-4].string_val), (yyvsp[-2].string_val), (yyvsp[0].string_val)

(IIUC) referencing the addresses under the top of the stack when passing 
$2, $4, $6 into a function from an action (skipping a couple of 
tokens).  So the sign just depends on which way the stack is growing.

As for range checking of pointers into a malloc'd block of memory, the 
pointer could have just 2 things: the address at the start of the block 
and the pointer itself, some moving address in the block; and then 
before the start of the block malloc could stash the address of the end 
of the block (where it could be referenced by all pointers into the 
block).  So instead of a triple word, the pointer is a double word, and 
the malloc'd block has an extra word before it.  This must have been 
done before by someone, somewhere.

I don't think of pointers and arrays in C as the same thing, but rather 
array references as an alternate syntax for pointer arithmetic (or vice 
versa).

- Aron