Jesse Pollard wrote:
> > One of the glibc people here pointed out that I shouldn't return the UID
> > from the set function as a 32 bit UID value could correspond to one of the
> > ERROR values (EPERM in this case) I'd want to return.
>
> You'll have to consider adding an address for the return value, and using the
> function return for the status.
--- Its a more general problem. Andreas Jaeger -- one of the glibc folks, tells me it is documented 'somewhere' that values in the range 0 - -4000 are reserved for kernel call error returns. The implication 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. Even if the semantics of 'read' are such that you can only read 4G at a time, to document that it is really only 4G-4000 looks a bit peculiar. I have no idea of which system calls might be affected. Looking at the kernel code for the get*uid functions, none of them can possibly return an error value, so all 32 bits could be valid. This implies there is a list (somewhere?) of kernel calls that can return full 32 bit values and no possibility of an error, and those that can't.This seems like it could affect several calls - waitpid, get*id, come to the top of mind. Seems like this is a potential 'gotcha'.
Design note?: Maybe all return values should only be allowed to be signed-integers with negative values meaning bad things? Seems cleaner to say uid's and pid's can only return a 31-bit unsigned value. Yeah, I know Albert will probably complain that it wipes out 2 billion some odd possible UID's and PID's, but it sure seems like it might be cleaner....or is this all a well documented issue that is really a non-problem?
-l
-- 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