On Fri, Sep 28, 2001 at 02:05:20AM -0400, Roland McGrath wrote: > The reason for the types in .defs files is for intran/outtran. I would > tend toward using the specific types generally, because that has more of a > chance to be mapped source-compatibly in some other RPC system.
I am doing this right now where feasible (like, I am doing it for host_t, but not for mach_port_name_t, esp as there is no typedef for the latter ;) It's only used internally to mark a MACH_MSG_TYPE_PORT_NAME parameter). But I am uncertain, as the interface definitions explicitely set the "ctype" to mach_port_t (that's what MiGs makes to put this type in the header). Maybe we should go and change those interface definitions were we prefer the specific types without ctype parameter? I am thinking of thread_t task_t, vm_task_t, ipc_space_t, host_t, host_priv_t, processor_t, processor_set_t, processor_set_name_t, memory_object_t, memory_object_name_t, memory_object_control_t, in mach_types.defs. Removing the ctype paramter in these places would make MiG to put the specific type in the header file prototype for the user rather than mach_port_t. This would make me feel better with using the specific type in the documentation as well. This would be consistent with what we do in the Hurd definition files, and as far as I can see there is nothing to worry about source or binary compatibility in any way. Oh, btw, we have two examples of subtyping here: vm_task_t and ipc_space_t are really task_t. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
