Q: Type'ing the infamous 'flags' field

[Mark A. Odell]

I write a lot of drivers and there is inevitably some hardware register or
buffer descriptor field called 'flags'. The flags are defined, typically,
as bit positions. I was thinking I could get some compile-time type
checking when assigning to a flag field but I don't think I can. Here's
what I was thinking:

typedef unsigned long HwFlag;
struct HwThing
{
SomeType fieldOne;
SomeType fieldTwo;
HwFlag flags;
};

static const HwFlag flagA = 1 << 0;
static const HwFlag flagB = 1 << 1;
static const HwFlag flagC = 1 << 2;

But the problem is when combining flags:

struct HwThing dev;

dev.flags = flagA | flagB;

I think I require a cast back to HwFlag since flagA and B will promote to
some integer type won't they? That is, I'd need to write:

dev.flags = (HwFlag) (flagA | flagB);

which rather defeats my intent. Any suggestions?

Thanks.

--
- Mark ->
--

[Dan Pop]

In <Xn************ *************** *****@130.133.1 .4> "Mark A. Odell" <od*******@hotm ail.com> writes:

I suspect you did not tell Carsten to "engage his brain".

I didn't have to: he always does.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

In <84************ **************@ posting.google. com> ol*****@inspire .net.nz (Old Wolf) writes:

"Mark A. Odell" <od*******@hotm ail.com> wrote:

static const HwFlag flagA = 1 << 0;
static const HwFlag flagB = 1 << 1;
static const HwFlag flagC = 1 << 2;

You should replace these '1's with '1UL'. For example if
int is 32bit and long is 64bit then 1 << 32 is undefined
behaviour.

As long as the shift count does not exceed 14 (and it doesn't in the
posted code), Mark's expressions are as correct and portable as you
can get. No need to replace 1 by anything else.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Mark A. Odell]

Linus Torvalds <to******@osdl. org> wrote in
news:ci******** **@build.pdx.os dl.net:

Mark A. Odell wrote:

I write a lot of drivers and there is inevitably some hardware register
or buffer descriptor field called 'flags'. The flags are defined,
typically, as bit positions. I was thinking I could get some
compile-time type checking when assigning to a flag field but I don't
think I can.

I'll mention the tool we use for the Linux kernel, because some people
on comp.lang.c migth actually find it interesting.

It's called "sparse" (for "semantic parse"), and it extends the C type
system with various flags (much of them for checking "address spaces" of
pointers, since the kernel has to work with pointers that are in
distinct address spaces like "user" and "iomem"), and it also solves
your particular problem.

What you do is make a integer typedef that is restricted to "bitwise"
operations:

#ifdef __CHECKER__ /* Magic sparse flag */
#define __bitwise __attribute__(( bitwise))
#else
#define __bitwise
#endif

typedef unsigned int __bitwise cmd_flag_t;

...
#define CMD_ACTIVE ((cmd_flag_t) 0x1000)

[snip]

Thanks for the reply Linus. This looks very interesting. We use Diab's
tool chain (not gcc) but there may be some way to do this. Of course we're
moving off into non-ISO C but that may be my only choice.

Regards.

--
- Mark ->
--

[Dave Thompson]

On 16 Sep 2004 19:25:40 GMT, Chris Torek <no****@torek.n et> wrote
(reordered slightly for convenience):

In article <news:Xn******* *************** **********@130. 133.1.4>
Mark A. Odell <od*******@hotm ail.com> wrote:

I write a lot of drivers and there is inevitably some hardware
register or buffer descriptor field called 'flags' [, usually just
some individual bits]. I [wish I] could get some compile-time type
checking when assigning [named constants] to a flag field ...
Any suggestions?
Ada. :-)

Ada really does have just what you want, *and* is (partly) designed
for use in small embedded systems. In many ways it is a shame we
all use C to program them instead. :-)

Concur. And FWIW Ada has language-defined (standardized) interface to
C. And Fortran and COBOL, which are less likely to be useful in a
lowlevel hardware application. The GNU implementation GNAT also does
C++ (g++) and will "play fairly nicely" in a C main -- I don't know
about others -- but the OP said elsethread he isn't using GNU.
Seriously, the only way to get serious type-checking in C is to
make new types, using C's type-creation mechanism, the "struct".
This is not generally compatible with low-level bit-twiddling.

You can do clever stuff in C++ at compile time with templates, so
that the actual code emitted is just straight integer values going
into the bit-field. This is incredibly ugly, though.

To be clear you can't template a type as such; you would template an
"integer-like" class containing inlined methods, which would as you
say actually compile the same as integers but with added type checks.

Or in C++ you can just use enum types. Unlike C where enum types and
values are just (syntactic sugar for) integers, in C++ they are
distinct types for purposes of overloading and conversion although
they still behave like integer types, and you can't (accidentally)
convert *to* a (different) enum type without a cast. (And also, a
minor point, they can be as wide as long, if that is wider than int.)

- David.Thompson1 at worldnet.att.ne t