Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Andy Valencia <vandys@vsta.org>
Newsgroups: comp.arch
Subject: Re: Segments
Date: Sat, 11 Jan 2025 13:59:21 -0800
Organization: A noiseless patient Spider
Lines: 21
Message-ID: <173663276157.23190.12092117245116719600@media.vsta.org>
References: <vlcddh$j2gr$1@paganini.bofh.team> <2025Jan5.121028@mips.complang.tuwien.ac.at> <vleuou$rv85$1@paganini.bofh.team> <ndamnjpnt8pkllatkdgq9qn2turaao1f0a@4ax.com> <2025Jan6.092443@mips.complang.tuwien.ac.at>
Injection-Date: Sat, 11 Jan 2025 23:04:12 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cc1b5fa0e4f63225eded39d269a364e4";
	logging-data="857197"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18PQas+P0PEZ+WsILZwodMv"
User-Agent: rn.py v0.0.1
Cancel-Lock: sha1:f3FZOArYXIaWMSRK8KPM8vk22hA=
Bytes: 2075

Terje Mathisen <terje.mathisen@tmsw.no> writes:
> The best idea I have seen to help detect out of bounds accesses, is to 
> round all requested memory blocks up to the next 4K boundary and mark 
> the next page as unavailable, then return a skewed pointer back, so that 
> the end of the requested region coincides with the end of the (last) 
> allocated page.

I think I've mentioned this once before, but I did precisely this during my
time at Sequent, and the C library blew up.  Turned out the C string support
routines were pulling in cache line lengths at a time, and it was such a win
they didn't want to observe "strict" C string access rules.  I assume they
padded things such that no "real life" string could end up against a page
boundary abutted to an invalid page address, but since they weren't
interested in fixing it, I stopped worrying about it.

A kinder, gentler time.  I wonder if such things still lurk out there.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html
Fediverse: @vandys@goto.vsta.org