[Asterisk-Dev] ast_flags question

[Andrew Thompson]

Kevin P. Fleming wrote:
> Yes, any specific module/struct that needs more than 32 flags will have 
> to declare a second flags variable in that struct.

So, should the macros be rewritten to allow referencing a specific flag 
variable? (Just hypothesizing, playing devil's advocate, learning, etc.)

> The "struct ast_flags" is used when you need a place to store flags 
> outside of any existing structure (temporary copies and such). Yes, that 
> struct could be extended, just as could any other struct that has a 
> "flags" variable now.

Ok, I was seeing the struct just as an object, existing only to insulate 
the coder from the actual low-level structure.

> The way the flags macros are currently written, using a 
> struct-inside-a-struct would just increase the amount of work for the 
> coder, for no additional gain. Also, it would force _all_ users of flags 
> to allocate 64 bits worth, even if they don't need them (if the struct 
> was extended to hold two sets of flags).

I guess that would defeat the purpose...

> As far as signed vs. unsigned, that was my suggestion, and Russell has 
> already converted chan_sip and chan_iax2 over to using "unsigned int". 

I haven't pulled a current CVS in a while, I was basing my statement 
strictly on that bugnote.

> If you know of any more places in current CVS that are using signed ints 
>  for flags, please post bugs in Mantis (with patches if you can). It's 
> only really important when you try to use bit number 31 or 32 in the 
> int, because then the compiler will sign-extend the value behind your 
> back :-)

I will pull a current copy and do some grep'ing. Patch is not something 
I'm yet familiar with, so we'll see how that turns out.

> I may try to modify the flags macros to generate compiler warnings if 
> someone uses them against a signed int... stay tuned :-)

See, that is why yall are writing this code, and I'm just standing 
around scratching my head.

-- 
Andrew Thompson
http://aktzero.com/
http://dev.asteriskdocs.org/