* [COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C
[not found] ` <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org>
@ 2024-09-20 15:56 ` Stuff Received
2024-09-20 17:15 ` segaloco via COFF
[not found] ` <20240920171126.vgtl23xwj37kardb@illithid>
1 sibling, 1 reply; 4+ messages in thread
From: Stuff Received @ 2024-09-20 15:56 UTC (permalink / raw)
To: COFF
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C
2024-09-20 15:56 ` [COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C Stuff Received
@ 2024-09-20 17:15 ` segaloco via COFF
0 siblings, 0 replies; 4+ messages in thread
From: segaloco via COFF @ 2024-09-20 17:15 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <20240920171126.vgtl23xwj37kardb@illithid>]
* [COFF] Re: [TUHS] Maximum Array Sizes in 16 bit C
@ 2024-09-21 0:22 Douglas McIlroy
2024-09-23 12:12 ` [COFF] " Ralph Corderoy
0 siblings, 1 reply; 4+ messages in thread
From: Douglas McIlroy @ 2024-09-21 0:22 UTC (permalink / raw)
To: COFF, Dan Cross
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
Moved to Coff, because it's about programming style, not history.
> Perhaps I'm missing something? Clever arithmetic in the index
> calculation aside, this is semantically different than using an actual
> negative integer to index into an array? Moreover, if the intent is to
> start the sequence with 0, why set `fib(0)` to 1? How is this
> substantially different from the usual way of writing this:
I said the Fibonacci example was silly. Maybe you'll be more convinced by
the binomial-coefficient program below.
The array of interest is fib. base is simply scaffolding and doesn't appear
in the working code. You won't find the ith Fibonacci in base[i]; it's in
fib(i). But fib(-1) exists. What's important is that the C convention of
array indexes beginning at 0 has been circumvented.
I could be accused of subterfuge in depending on the semantics of static
storage to initialize fib(-1) to zero. Subterfuge or not, it's customary C
usage. The binomial-coefficient program relies on "out-of-bounds" zeros
abutting two sides of a triangle.
int base[N][N+2];
#define binom(n,i) base[n][(i)+1]
void fill() {
binom(0,0) = 1;
for(n=1; n<N; n++)
for(i=0; i<=n; i++)
binom(n,i) = binom(n-1,i) + binom(n,i-1);
}
I think the offset algorithm above looks better than the more typical one
below.
The two programs happen to have identical character counts.
int binom[N][N+1];
void fill() {
for(n=0; n<N; n++) {
binom[n][0] = 1;
for(i=1; i<n; i++)
binom[n][i] = binom[n-1][i] + binom[n][i-1];
binom[n][n] = 1;
}
}
Doug
[-- Attachment #2: Type: text/html, Size: 2376 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [COFF] Re: Maximum Array Sizes in 16 bit C
2024-09-21 0:22 [COFF] Re: [TUHS] " Douglas McIlroy
@ 2024-09-23 12:12 ` Ralph Corderoy
0 siblings, 0 replies; 4+ messages in thread
From: Ralph Corderoy @ 2024-09-23 12:12 UTC (permalink / raw)
To: Douglas McIlroy; +Cc: COFF
Hi Doug,
> int base[N][N+2];
> #define binom(n,i) base[n][(i)+1]
Thanks for the interesting prompt. I've been having a think about it
along the lines of sliding the ints in memory.
Have you considered having a single dimension of ints and then accessing
them as if a two-dimensional array, with [0][0] being offset?
$ cat offset.c
#include <stdio.h>
#define N 4 // N×N values
#define L 3 // L columns of 0 to the left
#define U 2 // U columns of 0 upwards
int main()
{
char m[(U + N) * (L + N)] =
"abcdefg"
"hijklmn"
"opq+BCD" // The '+' is a[0][0].
"rstEFGH"
"uvwIJKL"
"xyzMNOP";
char (*a)[L + N] = (char (*)[L + N])&m[U * (L + N) + L];
for (int y = -U; y < N; y++) {
if (!y)
putchar('\n');
for (int x = -L; x < N; x++) {
if (!x)
putchar(' ');
putchar(a[y][x]); // y,x relative to ‘+’
}
putchar('\n');
}
}
$ gcc -Wall -Wextra -Werror offset.c
$ ./a.out
abc defg
hij klmn
opq +BCD
rst EFGH
uvw IJKL
xyz MNOP
$
--
Cheers, Ralph.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-09-29 0:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAKH6PiWvuxfa_ek=L=n=mgovFk_ms37u6F2N1qcMLs6RXLRWvA@mail.gmail.com>
[not found] ` <CAEdTPBfPcmZybb0CVLxhzB-nLTQb3aohWV-o_8ZqQJXmUc4yPA@mail.gmail.com>
[not found] ` <CAFH29to4_DFdx=U=ZRVY_HE0YGR8tw00Ya4PJhLGR4Z1UMF6_g@mail.gmail.com>
[not found] ` <CABH=_VR6=wJdgCLArHLd8q3N+BGj=5m16X4WBkB+o5XksbSsbw@mail.gmail.com>
[not found] ` <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org>
2024-09-20 15:56 ` [COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C Stuff Received
2024-09-20 17:15 ` segaloco via COFF
[not found] ` <20240920171126.vgtl23xwj37kardb@illithid>
[not found] ` <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org>
[not found] ` <CANCZdfpy9AsOfE+mvt+DkBYXiwfENLjscMHCT0nnU7WGz54T_Q@mail.gmail.com>
[not found] ` <0B54746F-504A-40E0-AFFD-4486167FBAD5@iitbombay.org>
2024-09-29 0:17 ` [COFF] " Aron Insinga
2024-09-21 0:22 [COFF] Re: [TUHS] " Douglas McIlroy
2024-09-23 12:12 ` [COFF] " Ralph Corderoy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).