Hi Caml-Riders,

When reading the sources of otherlibs/unix I saw that the
implementation just maps the result of getuid (and similar calls) to
ints. Remembering that (s) Ocaml has 32bit ints and (b) the Linux
kernel got changed to support 32bit UIDs some longer time ago I saw
the first beginnings of a problem.

Indeed I have create users with UIDs 2^31-1^ ... 2^31+1 and executed
this program 

  print_int (Unix.getuid ());
  print_newline();

under the respective accounts:

  # id bar
  uid=2147483647(bar) gid=2147483647 groups=2147483647
  # su bar
  $ ocaml unix.cma /tmp/x.ml
  -1

(hm ...)

  # id baz
  uid=2147483648(baz) gid=2147483648(bar) groups=2147483648(bar)
  # su baz
  su: Authentication service cannot retrieve authentication info.
  (Ignored)
  $ ocaml unix.cma /tmp/x.ml
  0

(gasp!)

  # id foo
  uid=2147483649(foo) gid=2147483649 groups=2147483649
  # su foo
  su: Authentication service cannot retrieve authentication info.
  (Ignored)
  $ ocaml unix.cma /tmp/x.ml
  1

(arrgs ...)

I could live with negative user ids, but the aliasing from 2^31 on is
certainly annoying.

Furthermore I admit that many of the system tools have problems with
user ids this large anyway: adduser silently truncates uid to 2^31-1
and su also seems to have some funny problems (as illustrated above).

Still, I find the situation unsatisfactory, esp. when one wants to
write system management tools with OCaml.

A check in the Unix library would be nice, in the long run I think
using 32bit native integers is absolutely required. 

BTW: I also had a look into the current POSIX and at the first glance
couldn't discover a constant that describes the maximum of uid_t (the
result type of getuid()). It only guaranteed to be "of integer type"
which in my eyes makes using everything smaller than long long int as
variable type for processing UIDs unportable and prone to break on
some other platform (admitted: this is not probably now, it's just
annoying that the standard doesn't give enough guarantees or at least
a constant for compile time configuration to make any decisions here).

Back to the topic: 
 
 (a) I'm just reporting this here for dicumentation.

 (b) Shall I report this as bug? And at the INRIA team: Is a reworking
     of Unix planned in the forseeable time or would interested
     parties have to it themselves? I'm just asking to avoid
     duplication of work: At the moment this is not high on my list of
     priorities anyway.

Regards -- Markus