any value in a standard for defining bit flags?

[Paul Fox]

 > 
 >   i don't feel like doing any real work so i'm just going to
 > pontificate.  the code for defining bit flags in BB is a little
 > chaotic as there are three standards scattered throughout the code.
 ...
 >   wouldn't it be easier to pick one and go with that?  certainly,

while i'm a fan of uniformity, and consistency, in most programs,
i'm also a fan of artistic license, and programmer preference. 
the fact is that busybox applets all come from different places,
and have different authors, and many are even sometimes still
synced, with greater or lesser rigor, with external codebases.

while i myself would never define bit numbers in decimal, i have
no problem maintaining them, or spotting errors in them.  i guess
all i'm getting at is that this is pretty far down on my list of
busybox peeves.  and since these definitions will never all appear
in a single header, i'm not sure where the "easier" part of your
claim comes in.  (what's "easiest" when i'm writing an applet is
probably to use what i find most natural.)

[ i guess what i find myself thinking is that the very next step
after something like this will be someone calling for a standard
format for comments...  ]

paul

 > 
 >   there's using shifts, as in tar.c:
 > 
 > #define CTX_TEST                          (1 << 0)
 > #define CTX_EXTRACT                       (1 << 1)
 > #define TAR_OPT_BASEDIR                   (1 << 2)
 > #define TAR_OPT_TARNAME                   (1 << 3)
 > #define TAR_OPT_2STDOUT                   (1 << 4)
 > #define TAR_OPT_P                         (1 << 5)
 > #define TAR_OPT_VERBOSE                   (1 << 6)
 > #define TAR_OPT_KEEP_OLD                  (1 << 7)
 > 
 >   then there's using hex literals, like in ext2_fs.h:
 > 
 > #define EXT2_SECRM_FL           0x00000001 /* Secure deletion */
 > #define EXT2_UNRM_FL            0x00000002 /* Undelete */
 > #define EXT2_COMPR_FL           0x00000004 /* Compress file */
 > #define EXT2_SYNC_FL            0x00000008 /* Synchronous updates */
 > #define EXT2_IMMUTABLE_FL       0x00000010 /* Immutable file */
 > #define EXT2_APPEND_FL          0x00000020 /* writes to file may only
 > append */
 > #define EXT2_NODUMP_FL          0x00000040 /* do not dump file */
 > #define EXT2_NOATIME_FL         0x00000080 /* do not update atime */
 > 
 >   and finally, there's just plain integer literals, as in sort.c:
 > 
 > /* These are sort types */
 > #define FLAG_n          1       /* Numeric sort */
 > #define FLAG_g          2       /* Sort using strtod() */
 > #define FLAG_M          4       /* Sort date */
 > /* ucsz apply to root level only, not keys.  b at root level implies
 > bb */
 > #define FLAG_u          8       /* Unique */
 > #define FLAG_c          16      /* Check: no output, exit(!ordered) */
 > #define FLAG_s          32      /* Stable sort, no ascii fallback at
 > end */
 > #define FLAG_z          64      /* Input is null terminated, not \n */
 > /* These can be applied to search keys, the previous four can't */
 > #define FLAG_b          128     /* Ignore leading blanks */
 > #define FLAG_r          256     /* Reverse */
 > #define FLAG_d          512     /* Ignore !(isalnum()|isspace()) */
 > #define FLAG_f          1024    /* Force uppercase */
 > #define FLAG_i          2048    /* Ignore !isprint() */
 > #define FLAG_bb         32768   /* Ignore trailing blanks  */
 > 
 > either of the first two syntaxes makes more sense than the last one,
 > but just having a single standard couldn't hurt.
 > 
 >   and wouldn't it make more sense to use an enum rather than just a
 > set of defines, anyway?
 > 
 > rday
 > 
 > _______________________________________________
 > busybox mailing list
 > busybox at busybox.net
 > http://busybox.net/cgi-bin/mailman/listinfo/busybox

=---------------------
 paul fox, pgf at brightstareng.com