From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sat, 10 Nov 2007 12:55:52 -0500 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Bounds checking bug in fcall(2) functions In-Reply-To: <815f4e4b0711091501v53a37569x5c5f576623fb9547@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <815f4e4b0711091420n2f6e9607nab13575f356b78d0@mail.gmail.com> <15aabbdb3c4953608a4f19497b3bffb0@terzarima.net> <815f4e4b0711091501v53a37569x5c5f576623fb9547@mail.gmail.com> Topicbox-Message-UUID: f1da5706-ead2-11e9-9d60-3106f5b1d025 > 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 :). Sorry about the buggy > bug report. The buffer can't be right at the end of the virtual memory space. The C standard guarantees (or rather, requires) that whenever you've got an allocated buffer, computing the pointer just past (some would say at) the end of the buffer can be done without address overflow, precisely because that kind of bounds check is such a common idiom. Russ