Re: libgit2 - a true git library
- From
Pierre Habouzit <madcoder@debian.org>
- Date
- Nov 1, 2008, 17:01 UTC
- Message-ID
- <20081101170158.GB26229@artemis.corp>
- In-Reply-To
- <alpine.LFD.2.00.0811010944000.13034@xanadu.home>
On Sat, Nov 01, 2008 at 01:50:45PM +0000, Nicolas Pitre wrote:
Show 13 quoted lines
> On Sat, 1 Nov 2008, Pierre Habouzit wrote: > > > Well, you can't return _sanely_ an error through a pointer. The &1 > > method is broken as soon as you return a char* (there is an alignment > > requirement for malloc, not for any pointer out there), hence shall not > > be used, as it would not be the sole way to test for error. > > > > Another option, that is _theorically_ not portable, but is ttbomk on all > > the platforms we intend to support (IOW POSIX-ish and windows), is to > > use "small" values of the pointers for errors. [NULL .. (void *)(PAGE_SIZE - 1)[ > > cannot exist, which gives us probably always 512 different errors, and > > 4095 actually. You don't need to align error codes.
Sure, I'm just not sure there isn't an arch where a page would be 512 octets. And you really have 4096 errors, from 0 to 4095 *included* :)
Show 8 quoted lines
> > the test is ((uintptr_t)ptr < (PAGE_SIZE)) which is cheap. It's butt > > ugly, but encoding errors into pointers is butt ugly in the first place. > > Or use "negative" pointers. Again, please have a look at > include/linux/err.h. The pointer range from 0xffffffff (or > 0xffffffffffffffff on 64-bit machines) down to the range you want is for > errors, and the top of the address range is almost certain to never be > valid in user space either.
Indeed.
-- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org