From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Wed, 5 Mar 2008 16:21:49 +0000 From: "Douglas A. Gwyn" Message-ID: <47CEC68A.3A62779D@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20080303161756.820A71E8C51@holo.morphisms.net>, <20080304044330.C6B7D1E8C55@holo.morphisms.net> Subject: Re: [9fans] plan9port build failure on Linux (debian) Topicbox-Message-UUID: 6f7edefc-ead3-11e9-9d60-3106f5b1d025 Russ Cox wrote: > The test for wraparound when computing len in sprint looks like: > len = 1<<30; /* big number, but sprint is deprecated anyway */ > /* > * on PowerPC, the stack is near the top of memory, so > * we must be sure not to overflow a 32-bit pointer. > */ > if(buf+len < buf) > len = -(uintptr)buf-1; There are several serious portability issues with that. The main thing is that casting a pointer to an integer type does not in general produce a "byte address", but rather just some encoding that can be converted back to a pointer. And of course buf+len produces undefined behavior if buf does not point to an array of length at least len. Such an address-range check chould be delegated to an auxiliary function that is tailored to the platform as part of the porting process. That way whatever nonportable kludge is used won't silently find its way into a port where it doesn't work.