From: Paul Winalski <paul.winalski@gmail.com>
To: Rich Salz <rich.salz@gmail.com>
Cc: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>,
TUHS main list <tuhs@tuhs.org>
Subject: [TUHS] Re: Maximum Array Sizes in 16 bit C
Date: Fri, 20 Sep 2024 09:33:32 -0400 [thread overview]
Message-ID: <CABH=_VR6=wJdgCLArHLd8q3N+BGj=5m16X4WBkB+o5XksbSsbw@mail.gmail.com> (raw)
In-Reply-To: <CAFH29to4_DFdx=U=ZRVY_HE0YGR8tw00Ya4PJhLGR4Z1UMF6_g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]
On Thu, Sep 19, 2024 at 7:52 PM Rich Salz <rich.salz@gmail.com> wrote:
>
> In my first C programming job I saw the source to V7 grep which had a
> "foo[-2]" construct.
>
That sort of thing is very dangerous with modern compilers. Does K&R C
require that variables be allocated in the order that they are declared?
If not, you're playing with fire. To get decent performance out of modern
processors, the compiler must perform data placement to maximize cache
efficiency, and that practically guarantees that you can't rely on
out-of-bounds array references.
Unless "foo" were a pointer that the programmer explicitly pointed to the
inside of a larger data structure. In that case you could guarantee that
the construct would work reliably. But by pointing into the middle of
another data structure you've created a data aliasing situation, and that
complicates compiler data flow analysis and can block important
optimizations.
Things were much simpler when V7 was written.
-Paul W.
[-- Attachment #2: Type: text/html, Size: 1457 bytes --]
next prev parent reply other threads:[~2024-09-20 13:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-18 23:51 Douglas McIlroy
2024-09-18 23:57 ` Henry Bent
2024-09-19 13:13 ` Rich Salz
2024-09-20 13:33 ` Paul Winalski [this message]
2024-09-20 15:07 ` Dave Horsfall
2024-09-20 15:30 ` Larry McVoy
2024-09-20 15:56 ` Stuff Received
2024-09-20 16:14 ` Dan Cross
2024-09-20 17:11 ` G. Branden Robinson
2024-09-20 20:16 ` Bakul Shah via TUHS
2024-09-20 20:58 ` Warner Losh
2024-09-20 21:18 ` Rob Pike
2024-09-20 22:04 ` Bakul Shah via TUHS
2024-09-20 22:19 ` G. Branden Robinson
2024-09-20 15:26 ` Rich Salz
2024-09-20 19:40 ` Leah Neukirchen
2024-09-20 15:24 Douglas McIlroy
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='CABH=_VR6=wJdgCLArHLd8q3N+BGj=5m16X4WBkB+o5XksbSsbw@mail.gmail.com' \
--to=paul.winalski@gmail.com \
--cc=douglas.mcilroy@dartmouth.edu \
--cc=rich.salz@gmail.com \
--cc=tuhs@tuhs.org \
/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).