Borislav Deianov wrote:
> PIDs are signed int and currently limited to 0x8000, so they don't
> have a problem.
--- So if we went to a 32-bit pid at some point in the future, that would likely be limited as well.> > UIDs are unsigned int. The only calls that return uid_t (getuid and > geteuid) cannot fail, so there's no problem here either. --- Can't currently fail. I dunno about future -- can't think of a scenario, but my imagination is finite.
> What is "etc" above? We can be careful when adding new system calls so > we don't run into this in the future. --- times should added to the list of 'never failing functions' 'dup' is treated special -- shouldn't ever be a problem (by my finite imagination again :-)) 'getgroups' special same way, again shouldn't be a problem
There are a few others where return value is used to indicate a 'positive' value (items returned) or a -1 on failure -- they would all fall into the 'read' class of return values and so aren't problems.
So it would appear, really, that only disallowed UID value would be 0xffff[ffff]. So in the glib files, they need to make sure not to disallow UID's >0x8fff ffff.
Ok dok.
Copacetic to me... -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