From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <c03ff139454ba47fe3365466ffc8a5e4@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 16 Nov 2007 05:38:24 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Bounds checking bug ifcall(2) functions
In-Reply-To: <473CA225.86119D3C@null.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: fd0a1828-ead2-11e9-9d60-3106f5b1d025

> Erik Dal=C3=A9n wrote:
> > On second thought I think you are correct. At the end of the function
> > the pointer might be one byte past the buffer size, but then it won't
> > do any reads or writes (But it could be a problem if the buffer is
> > right at the end of the virtual memory space :).
>=20
> The C standard requires that pointer arithmetic work properly
> for one-past-the-end pointers.  On some architectures that may
> mean that each data segment has to have an extra (unused) byte
> allocated, but on most architectures nothing special has to be
> done.

i think what he's saying is that for machines with unsigned ptr
arithmetic, on a 16-bit machine, ~0 (0xffff) is not a legal address;
on a 32-bit machine ~0 (0xffffff) is not a legal address; &c.  on a
machine with page-based vm, i think this means the highest page=20
isn't kosher.  (if signed, the problem is at 0x7f(ff)*.)  this is because
for all addresses a except ~0 a < a+1.  i suppose you could hand
out all but the last 2 bytes of the final page.

i don't think it means you have to allocate an extra byte. there's
no requirement that you may indirect the "one-past the end" address.

- erik