Could anyone take another look at this patch?
Thanks
On 31 December 2015 at 15:28, Flavio Cruz <flavioc...@gmail.com> wrote:
> On Thu, Dec 31, 2015 at 03:11:44PM +0100, Justus Winter wrote:
> > Quoting Flavio Cruz (2015-12-30 18:03:58)
> > > This fixes a warning when compiling the mig generated file
> > > gnumach/kern/mach4.server.c. Here, an ipc_port_t* is passed to a
> > > function that expects a mach_port_t* (In0P->object). Since mig uses
> > > mach_port_t and ipc_port_t interchangeably in kernel interfaces, we
> need
> > > to use casts to make GCC happy.
> >
> > Are you thinking of this issue:
> >
> > kern/mach4.server.c: In function ‘_Xmemory_object_create_proxy’:
> > kern/mach4.server.c:691:73: warning: passing argument 3 of
> ‘memory_object_create_proxy’ from incompatible pointer type
> [-Wincompatible-pointer-types]
> > OutP->RetCode = memory_object_create_proxy(task, In0P->max_protection,
> In0P->object, In0P->objectType.msgt_number, In1P->offset,
> In1P->offsetType.msgt_number, In2P->start, In2P->startType.msgt_number,
> In3P->len, In3P->lenType.msgt_number, &OutP->proxy);
> > kern/mach4.server.c:585:29: note: expected ‘memory_object_array_t {aka
> long unsigned int *}’ but argument is of type ‘struct ipc_port **’
> > mig_external kern_return_t memory_object_create_proxy
> >
> > ?
>
> Yes.
>
> >
> > I've been wondering about that, but didn't took a closer look. I
> > always assumed that this is due to MatchMakers poor type support.
>
> In this case it's related to the way mig handles ipc_port_t objects and
> mach_port_t names internally.
>
> >
> > Cheers,
> > Justus
>
> Cheers
> Flavio
>
--
Flávio Cruz / flavioc...@gmail.com
