From: segaloco via COFF <coff@tuhs.org>
To: COFF <coff@tuhs.org>
Subject: [COFF] Re: [TUHS] Re: Maximum Array Sizes in 16 bit C
Date: Fri, 20 Sep 2024 17:15:28 +0000 [thread overview]
Message-ID: <en7DrX6AXQ9tqrVNFcVARKQD-LdjDhr6fJvinzLM6edrRMMSL-hm8wkxZBTHLAwnnObBZY9J6PTn4PA0pKWIo2pNvheEy1g03GmKt4aRvR8=@protonmail.com> (raw)
In-Reply-To: <d6386cb3-f8ec-bd17-9d0a-e7f5272dd12b@riddermarkfarm.ca>
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.
next prev parent reply other threads:[~2024-09-20 17:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 ` Stuff Received
2024-09-20 17:15 ` segaloco via COFF [this message]
[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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='en7DrX6AXQ9tqrVNFcVARKQD-LdjDhr6fJvinzLM6edrRMMSL-hm8wkxZBTHLAwnnObBZY9J6PTn4PA0pKWIo2pNvheEy1g03GmKt4aRvR8=@protonmail.com' \
--to=coff@tuhs.org \
--cc=segaloco@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).