BTW, I am thiking more clearly now and realize I initially confused
the uap struct in lock() with u_uap, although what is actually assigned is
uap->linkname to u.u_dirp.
When seeing the type definitions in param.h I also notice that it
defines caddr_t (the type of the u.u_dirp.l side of the saddr_t union) as
typedef char *caddr_t; /* pointer to kernel things */
that leads me to consider that the &0x7F00FFFF may be an additional
security check to ensure that the pointer falls within valid memory
space, in which case it would match the memory map.
I notice that nsseg in mch.s may return %7F00 on some cases and is used
in machdep.c as stseg = nsseg(u_state->s_sp); so it seems the stack uses
segment 0x7F00. Then may be the & is shorthand to make sure the address
pointed by the ANDed pointer falls within the stack. It would probably
imply user programs have a maximum stack size of 65536 bytes as well.
That may explain why some pointers are ANDed and others not. I haven't
had a thorough look, but if the &0x7F00FFFF usage is consistent, then
that's is an explanation that may guide source reconstruction.
Does this look sensible?
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural