Flag Bitset, evitando colisiones, c

Question

Tengo un número entero que tiene un conjunto existente de posibles banderas:

#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 */

Necesito agregar uno nuevo:

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

¿Hay alguna razón por la que la lista de bandera existente se salte desde 0x0200 hasta 0x8000? Entiendo que los valores utilizables para mi nueva bandera serían 0x0400, 0x0800 y 0x1000-0x4000. ¿Estoy malinterpretando algo sobre cómo funcionan estos bitsets?

Answer 1

Sí, tienes razón: esos valores de bandera faltantes se pueden usar en teoría, a menos que estén reservados para otra cosa.

Tendría que consultar con el autor original si hay alguna razón específica por la que fueron omitidos y subieron directamente a 0x8000.

Ciertamente no hay intrínseco Comportamiento en campos de bit que evitarían su uso.

Answer 2

En pocas palabras, su comprensión está bien.

Solo podemos adivinar por qué MAIL_DELETED es 0x8000 Y no, digamos, 0x0400; Supongo que el más alto se eligió debido a la naturaleza dramática de la bandera "eliminada".

La parte más complicada de introducir un nuevo bit en la máscara de bits de otra persona es que debe asegurarse de que los bits que parecen no usar en realidad no se usan y que siempre se inicializan de manera consistente.

Answer 3

Todo depende de quién lo escribió en cuanto a lo que ellos quiso decir por sus posiciones de bit elegidas. Sin embargo, por lo que puedo ver, parece que agruparon las banderas de bit lógicamente en bytes.

Para el tuyo, podrías presentar un caso para:

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

Ya que parece un estado similar al nuevo o borrador pero no se elimina.

Answer 4

No estoy familiarizado con su aplicación, pero en teoría, los valores 0x400,0x800,0x1000,0x2000 y 0x4000 no están definidos y se ajustan perfectamente a sus otras define, por lo que puede agregar una nueva definición con esos valores.

Answer 5

Suena como una mala documentación para mí. Habría colocado Mail_Flag_Unused en las últimas ranuras de bits para que fuera obvio que estaban disponibles. Verifique para asegurarse de que Mail_new no esté utilizando los bits más altos para algún tipo de valor incrustado, pero en la superficie, parece tener un montón de bits disponibles desde 0x0400 hasta 0x4000.