Philipp Rumpf wrote:
>
> > Its a more general problem. Andreas Jaeger -- one of the glibc
> > folks, tells me it is documented 'somewhere' that values in the range
>
> It's been on the relevant mailing lists, glibc source has it.
>
> > 0 - -4000 are reserved for kernel call error returns. The implication
>
> -4095, in fact.
--- When the kernel goes to 32-bit pids (if it hasn't already, does it know to skip from 0xfffff000 to 0? More importantly -- the "relevant mailing lists" aren't read by system administrators who might try assigning UID's like -5000 or -4000 or their equivalent unsigned values. Maybe we should just treat pids and uid's, etc as consistent 31 bit values? Seems less error prone/confusing in the long run.> > > is that any function (include things like getuid()) can't return > > a a full 32-bit unsigned value as the top 4000 numbers would be reserved. > > Read can't return a full 4G-1 -- which if fine for some file systems, but > > certainly not 64-bit file systems. > > Yes it is. For read to return 4G-1 you'd have to have a buffer including > every single virtual page - NULL page, virtual addresses reserved for the > kernel, stack. --- Not on a 64 bit machine -- but I guess return values will be 64 bit as well there. I guess I still don't like the inconsistency for pid's and uid's that are said to be 32 unsigned bits but really aren't.
> glibc handles it by _always_ treating 0xfffff000 - 0xffffffff as errors > rather than keeping lists. --- That's going to be a "support" headache eventually for someone...
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:15 EST