On Sat, Jan 08, 2005 at 10:24:02AM -0700, Kevin P. Fleming wrote:
> Mike M wrote:
>
> >Election to avoid bit definition on new design is correct.
>
> But this discussion is really not about protocols, or anything external
It is if you think about protocols in a wider sense. Besides the
reference to comm. protocols was to illustrate where bit definitions
are needed. Elsewhere they are unnecessary and should be avoided.
As to CPU cache flushing versus CPU cycles for bit isolating, that's
splitting hairs. Do Asterisk developers concern themshelves with CPU
cache management?
Bit definitions are CPU endian gnostic too. For example:
struct blah {
#if ENDIAN == LITTLE
int a : 1 PACKED;
int b : 7 PACKED;
#else
int b : 7 PACKED;
int a : 1 PACKED;
#endif
};
See /usr/include/linux/tcp.h for another example.
See asterisk-1.0.3/dns.c (and ref. RFC 2535 Section 6.1)
These examples show proper use of bitfields. They accommodate old
protocols.
New software designs (including new protocols) avoid bitfield
definitions for easier human comprehension and easier porting to
various CPU architectures.
_______________________________________________
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
