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?
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.