Andrew Thompson wrote:
What they are talking about now, is putting all the variables that the flags were were supposed to represent back in as defined variables, but this time, using the variablename:X format to specify how many bits the variable should take up.
Exactly. Let the compiler figure out how to combine 11 variables that take up one or two bits each into storage in the struct, and let it build the code to access them however it feels it best (as opposed to using the existing macros). Where this really shines is in the cases where have "flags" that have more than two values and require two bits or more; the existing code for manipulating those is non-intuitive and somewhat error-prone. Letting the compiler handle it would solve that problem completely.
I also have been looking through references to "flags" for making sure that they were all using unsigned int's, as mentioned before.
They already are, and in fact the current macros in CVS HEAD won't compile if you don't use an "unsigned int" variable for flags, so that's no longer an issue.
I am now confused as to what direction flags are going.
There is no "direction" at this point, only a small group of us who feel that switching to compiler-built bitfields (instead of #define-d values stored in an int variable) would be worthwhile and a significant improvement in the code's readability and maintainability. What I proposed to the OP was that he produce a sample conversion of one of the more complicated modules (chan_sip) so that everyone can see what the actual code would look like, rather than trying to get assent/approval for something that hasn't been seen yet.
_______________________________________________
Asterisk-Dev mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
