On Sat, Sep 29, 2001 at 09:56:05PM -0400, Roland McGrath wrote:
> There is probably some obscure reason having to do with mig stubs in the
> kernel why those ctype declarations are there. At any rate, I'm
> disinclined to fiddle with the .defs files.
Ah, this is indeed true. A simple test shows
> 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).
mach_port_name_t is not a port type at all. It is the type of port na
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
Roland McGrath <[EMAIL PROTECTED]> writes:
> There are probably a few weird hacks that rely on true port polymorphism.
> But most of the uses can be described as interface subtyping (e.g. file_t
> and socket_t are subtypes of io_t).
The auth server, for example, hands ports around, and they are
There are probably a few weird hacks that rely on true port polymorphism.
But most of the uses can be described as interface subtyping (e.g. file_t
and socket_t are subtypes of io_t).
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mail
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.
___
Bug-hurd mailing list
[EMAIL PROTECTED
On Fri, Sep 28, 2001 at 01:23:25AM +0200, Farid Hajji wrote:
> * are the more specific types at least _consistently_ used?
> I doubt this is the case: a lot of files simply fall back to
> mach_port_t later
> * are they really needed for architectural reasons, or, more
> precisely,
Hi Marcus,
> I saw that the defs file have nice specific types like ipc_space_t and
> mach_port_name_t, but the C header files almost all have mach_port_t for
> them. In the Hurd, we have a typedef for each of these types and keep
> them in the header. We even use task_t in proc etc.
>
> I am
