On Thu, 30 Sep 1999, Brett Lymn wrote:

# According to der Mouse:
# >
# >The biggest problem with this, aside from the nonportability various
# >people have commented on, is that it becomes impossible to manipulate
# >multiple bits at the same time.  This can be important for setting and
# >clearing bits and can be useful when testing bits.
# >
# 
# *shrug* just union the bit fields with an appropriate sized unsigned
# integer(s).

That seems like a lot of work for a little gain.  I was going to say
it was messy, but not really.

If you're going to use a union, you've just added another layer
in which you need to use a . or a ->; that seems pretty silly to me.

gcc does enums correctly, does it not?  Why not use enums and some
macros and be done with it?

(Factually, I used to use macros, but I got to the point where it was
just easier to use raw code, i.e.,
	p->p_flags |= (VALUE1|VALUE2) &~ (VALUE3);
)

# >
# >More important, which is more comfortable for our kernel hackers?  For
# >what it's worth, I feel more comfortable with #defines.
# >

I'm a kernel hacker wannabe -- the best I ever did was to tie in
QUOTA with the chown() ability for non-super-users, back before
POSIX, much less POSIX_CHOWN_RESTRICTED, entered the scene.
[And I twiddled some kernel messages for fun, but that doesn't
really count, either.]

[[and here I am with the SunOS source for an Antares 4-port
 Sbus card and not quite sure how to proceed.  Hah.]]

# I prefer bit fields :-)

I thought they were kinda neeto when I first discovered them, but
unless you've got a processor that handles them intrinsically (and
a compiler to make use of it), they use more cycles than they're
worth.  I've come to appreciate #defines/enums, myself.

				--*greywolf;
--
NetBSD: You can't handle it.  (Well, maybe this group could.)