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. > 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. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
