This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
RE: Side Mask
- From: "Stanley Sutton" <sutton at t-surf dot com>
- To: "Hans Ronne" <hronne at pp dot sbbs dot se>
- Cc: <xconq7 at sources dot redhat dot com>
- Date: Tue, 23 Jul 2002 13:34:16 -0500
- Subject: RE: Side Mask
I was wondering if there was a reason for it, since it's a fairly
obvious problem. If you want to leave the way it is, let me know, and
I'll just document the behavior for future readers. :-)
-----Original Message-----
From: Hans Ronne [mailto:hronne@pp.sbbs.se]
Sent: Tue 23-Jul-02 13:12
To: Stanley Sutton
Cc: xconq7@sources.redhat.com
Subject: Re: Side Mask
>Currently, the side mask set operation is defined as:
>
>#define add_side_to_set(side,mask) ((mask) | (1 << ((side) ? (side)->id
>: 0)))
>
>It would seem to be better to define it as:
>
>#define add_side_to_set(side,mask) ((mask) | ((side)?(1 << (side)->id)
:
>0)))
>
>since that would not modify the mask if the side pointer is null, where
>the current definition would set the 0'th (or 31st depending on how you
>number the bits) bit if the side mask is null. If the side id can be 0
>(which I haven't dug through the code to find out), side 0 or a null
>poiter would set the same bit. The remove side from mask would need a
>similar correction.
The indepside (which always exists even if it has no units) has side id
0.
All these checks for null side pointers are remnants from the time when
independent units did not have a side at all. So you had to check if a
unit
had a side before dereferencing it. This is no longer so, every unit has
a
side. So I don't think the problem with a null side being passed to this
macro would ever occur. But I will check to make sure.
Hans
Hans Ronne
hronne@pp.sbbs.se