[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug located (was: Re: gdb, libio, readline

From: Marcus Brinkmann
Subject: Re: bug located (was: Re: gdb, libio, readline
Date: Sun, 31 Mar 2002 22:04:06 +0200
User-agent: Mutt/1.3.27i

On Sun, Mar 31, 2002 at 09:45:07PM +0200, Niels Möller wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> What's the definition of mach_msg_type_t? I have the Hurd sources, but
> not Mach sources, around.

typedef struct  {
    unsigned int        msgt_name : 8,
                        msgt_size : 8,
                        msgt_number : 12,
                        msgt_inline : 1,
                        msgt_longform : 1,
                        msgt_deallocate : 1,
                        msgt_unused : 1;
} mach_msg_type_t;
> > On Sun, Mar 31, 2002 at 01:59:56AM +0100, Marcus Brinkmann wrote:
> > > ok, here is some hard data.  It turns out that the comparison:
> > >    *(int *) &msg.error.err_type == *(int *) &inttype
> Can you rewrite this without using the ugly explicit casts? If you
> want the first member foo (which is an integer) on both sides, you
> could simply write
>   msg.error.err_type.foo == inttype.foo
> Both foo:s must be of type int, although the explicit casts won't give
> you any warnings if they aren't. If they really are, I think it's a
> compiler error if you don't get the same results (the casts are ok,
> and the address-of operator should force the C compiler to allocate
> the objects the way one would expect). But a const static declaration
> and no use of the address-of operator would give the compiler more
> freedom to not allocate storage for inttype in the usual way.

As you can see, the goal is to compare all fields, and they all fit into a
single 32bit int, which is why it can load the whole struct into a register
and make the comparison.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]