I'm attempting to create a rtp library(yes i know there are many available) and the header needs to have the bits arranged in a certain sequence. however i've learned that the bit order is compiler dependant.
how can i gurantee dev will keep my bit field the way i have it and when i send it over the network with the payload it will be sent in the following order:
typedef struct{
unsigned short v: 2;/rtp version/
unsigned short p: 1; /rtp padding/
unsigned short x: 1;/extension bit/
unsigned short cc: 4;/csrc count/
unsigned short m: 1;/marker bit/
unsigned short pt: 7;/payload type/
unsigned short sn: 16;/sequence number/
unsigned int ts: 32;/time stamp/
unsigned int ssrc: 32;/synchronization source/
unsigned int csrc: 32;/contributing sources max 15/
}rtp_hdr;
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is not the compiler. The bit order in a struct is the same for all compilers. http://msdn2.microsoft.com/en-us/library/ewwyfdbe(VS.80).aspx
Go back a step and describe the problem you are having.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I was going to let this thread pass by me, but now I can't.
"The bit order in a struct is the same for all compilers."
This is complete crap! The "bit order" is not even the same for "normal" types across platforms. Any type derived from the "normal" types, including bit fields, are inherently dependent on the compiler in question.
OP, the only way to do this portably is to use behavior that can be managed directly. That is, code the bit logic yourself for each platform you plan to support. GCC may have an extension to help with this. Search!
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-06
The link he posted even says that! It does not support his argument at all - quite teh reverse it says:
[bold]Microsoft Specific[/bold]
The ordering of data declared as bit fields is from low to high bit, as shown in the figure above.
[bold]END Microsoft Specific[/bold]
OP: You need to shift/mask the bits in the order you want them. Because this does not account for byte order (which is architecture specific, but can reasonably be expected to be the same for all compilers for the same architecture), you need to use architecture specific code (normally through conditional compilation or architecture specific libraries) to modify for correct byte order where necessary. Where the required byte order is "TCP/IP network byte order" i.e. big-endian, then the htons() and htonl() functions in winsock.h (socket.h in BSD sockets) will handle that for you.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it's great that he didn't bother to find an article that supported his misunderstanding. He's combining a lack of knowledge with lack of follow through. We have just identified the perfect troll. ^_^
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm attempting to create a rtp library(yes i know there are many available) and the header needs to have the bits arranged in a certain sequence. however i've learned that the bit order is compiler dependant.
how can i gurantee dev will keep my bit field the way i have it and when i send it over the network with the payload it will be sent in the following order:
typedef struct{
unsigned short v: 2;/rtp version/
unsigned short p: 1; /rtp padding/
unsigned short x: 1;/extension bit/
unsigned short cc: 4;/csrc count/
unsigned short m: 1;/marker bit/
unsigned short pt: 7;/payload type/
unsigned short sn: 16;/sequence number/
unsigned int ts: 32;/time stamp/
unsigned int ssrc: 32;/synchronization source/
unsigned int csrc: 32;/contributing sources max 15/
}rtp_hdr;
thanks for the post guys. i understand the logic an reason behind it a bit better now.
wow. no one has anything to add? wayne? C? let me know please.
The problem is not the compiler. The bit order in a struct is the same for all compilers.
http://msdn2.microsoft.com/en-us/library/ewwyfdbe(VS.80).aspx
Go back a step and describe the problem you are having.
Well, I was going to let this thread pass by me, but now I can't.
"The bit order in a struct is the same for all compilers."
This is complete crap! The "bit order" is not even the same for "normal" types across platforms. Any type derived from the "normal" types, including bit fields, are inherently dependent on the compiler in question.
OP, the only way to do this portably is to use behavior that can be managed directly. That is, code the bit logic yourself for each platform you plan to support. GCC may have an extension to help with this. Search!
Soma
The link he posted even says that! It does not support his argument at all - quite teh reverse it says:
[bold]Microsoft Specific[/bold]
The ordering of data declared as bit fields is from low to high bit, as shown in the figure above.
[bold]END Microsoft Specific[/bold]
OP: You need to shift/mask the bits in the order you want them. Because this does not account for byte order (which is architecture specific, but can reasonably be expected to be the same for all compilers for the same architecture), you need to use architecture specific code (normally through conditional compilation or architecture specific libraries) to modify for correct byte order where necessary. Where the required byte order is "TCP/IP network byte order" i.e. big-endian, then the htons() and htonl() functions in winsock.h (socket.h in BSD sockets) will handle that for you.
Clifford
O_o
LOL
I think it's great that he didn't bother to find an article that supported his misunderstanding. He's combining a lack of knowledge with lack of follow through. We have just identified the perfect troll. ^_^
Soma