flag bitset, avoiding collisions, C

Question

I've got a flag-holding integer that has an existing set of possible flags:

#define MAIL_ADDR_FROM  0x0001  /* address field contains the from address */
#define MAIL_ADDR_TO    0x0002  /* address field contains the to address */
#define MAIL_SEEN       0x0004  /* message has been read by the user */
#define MAIL_ATTACH     0x0008  /* message has an attachment */
#define MAIL_IMP_HIGH   0x0010  /* message is of high importance */
#define MAIL_IMP_LOW    0x0020  /* message is of low importance */
#define MAIL_FLAGGED    0x0040  /* message has been flagged */
#define MAIL_REPLIED    0x0080  /* message has been replied to */
#define MAIL_DRAFT      0x0100  /* message is a draft */
#define MAIL_NEW        0x0200  /* message is new */
#define MAIL_DELETED    0x8000  /* message is deleted */

I need to add a new one:

#define MAIL_SPAM       0x????  /* message is spam */

Is there a reason the existing flag list skips from 0x0200 all the way to 0x8000? My understanding is that usable values for my new flag would be 0x0400, 0x0800 and 0x1000-0x4000. Am I misunderstanding something about how these bitsets work?

Could be reserved, or maybe they do not want you to know about it. — Joe, Nov 30 '11 at 16:33

score 3 · Answer 1 · answered Nov 30 '11 at 16:35

In a nutshell, your understanding is fine.

We can only guess why MAIL_DELETED is 0x8000 and not, say, 0x0400; my guess would be that the highest bit was chosen due to the dramatic nature of the "deleted" flag.

The trickiest part of introducing a new bit into somebody else's bitmask is that you need to make sure that the bits that appear unused are actually unused and that they are always initialized consistently.

score 2 · Accepted Answer · answered Nov 30 '11 at 16:34

Yes, you're correct - those missing flag values are in theory usable, unless they're reserved for something else.

You'd need to check with the original author if there's any specific reason why they were skipped and went straight up to 0x8000.

There's certainly no intrinsic behaviour in bit fields that would prevent their use.

score 2 · Answer 3 · answered Nov 30 '11 at 16:35

It all depends on who wrote it as to what they meant by their chosen bit positions. However, from what I can see it looks like they grouped the bit flags logically into bytes.

For yours, you could make a case for:

#define MAIL_SPAM        0x0400 /* message is spam */

Since it seems like a state similar to New or Draft but not Deleted.

score 0 · Answer 4 · answered Nov 30 '11 at 16:36

0

i'm not familiar with your application , but in theory , the values 0x400,0x800,0x1000,0x2000 and 0x4000 are not defined and fit perfectly to your other defines ,so you can add new define with those values.

answered Nov 30 '11 at 16:36

Gil.I

895
12
23

score 0 · Answer 5 · answered Nov 30 '11 at 16:37

0

Sounds like poor documentation to me. I'd have placed MAIL_FLAG_UNUSED in the last few bit slots so that it was obvious that they were available. Check to make sure that MAIL_NEW isn't using the higher bits for some sort of embedded value, but on the surface, you do appear to have a bunch of bits available from 0x0400 thru 0x4000.

answered Nov 30 '11 at 16:37

Michael Dorgan

12,453
3
31
61

Bah - too many 10k+ karma posters this morning. Back to work for me :) – Michael Dorgan Nov 30 '11 at 16:39

flag bitset, avoiding collisions, C

5 Answers5