This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with size of structers

Hi anybody

I declare the folowing stuctures:

typedef struct {
    ubyte	bLength;
    ubyte	bDescriptorType;
    ubyte	bInterfaceNumber;
    ubyte	bAlternateSetting;
    ubyte	bNumEndpoints;
    ubyte	bInterfaceClass;
    ubyte	bInterfaceSubClass;
    ubyte	bInterfaceProtocol;
    ubyte	iInterface;
} USB_interface_desc_t;

typedef struct {
    ubyte	bLength;
    ubyte	bDescriptorType;
    uword	wTotalLength;
    ubyte	bNumInterfaces;
    ubyte	bConfigurationValue;
    ubyte	iConfiguration;
    ubyte	bmAttributes;
    ubyte	MaxPower;
} USB_config_desc_t;


typedef struct {
    ubyte	bLength;
    ubyte	bDescriptorType;
    struct {
	ubyte address:4;
	ubyte reserved:3;
	ubyte direction:1;
    } bEndpointAddress;
    ubyte	bmAttributes;
    uword	wMaxPacketSize;
    ubyte	bInterval;
} USB_endpoint_desc_t;

typedef struct {
    USB_config_desc_t	usb_dev_config_desc;
    USB_interface_desc_t	usb_interface_0_alt_0_desc;
    USB_endpoint_desc_t	usb_dev_endpoint_alt_0_desc[2];
} USB_long_config_desc_t;

When I use the sizeof I obtain folowing values:

sizeof(USB_long_config_desc_t) = 0x24
sizeof(USB_endpoint_desc_t) = 0x08
sizeof(USB_interface_desc_t) = 0x09
sizeof(USB_config_desc_t) = 0x0A


What happens and what is wrong?

Thanks

Aram

Parents

  • While we're on the topic, I notice there are some bitfield declarations in the structure. Bitfield endianess (that is, whether they are allocated from the LSB first or MSB first) is implementation-specific, and is independent of multi-byte word endianness. Given the fragment

    struct
       {
       ubyte myBits:4;
       ubyte myOtherBits:4;
       } nibble;
    
       nibble.myBits = 0xF;
       nibble.myOtherBits = 0;
    

    nibble might wind up looking like either 0xF0 or 0x0F. So check the manuals or write a little test.

    ANSI also says that bitfields are always part of an 'int', so there's a potential portability issue for bitfields in other sizes like bytes. Most embedded compilers will let you specify other sizes for bitfields, but it's non-standard behavior.

    Oddly enough, even though ANSI-standard bitfields are "ints", whether or not they are signed is also left up to the implementation. int myBit:1 may take on the values 0 and 1, or 0 and -1, depending on your compiler. Plain "int" doesn't necessarily mean "signed int" in the context of bitfields (unlike its normal meaning), and if you have a concern for portability or even just clarity, you might want to always specify "signed int" or "unsigned int" to be sure.

Reply

  • While we're on the topic, I notice there are some bitfield declarations in the structure. Bitfield endianess (that is, whether they are allocated from the LSB first or MSB first) is implementation-specific, and is independent of multi-byte word endianness. Given the fragment

    struct
       {
       ubyte myBits:4;
       ubyte myOtherBits:4;
       } nibble;
    
       nibble.myBits = 0xF;
       nibble.myOtherBits = 0;
    

    nibble might wind up looking like either 0xF0 or 0x0F. So check the manuals or write a little test.

    ANSI also says that bitfields are always part of an 'int', so there's a potential portability issue for bitfields in other sizes like bytes. Most embedded compilers will let you specify other sizes for bitfields, but it's non-standard behavior.

    Oddly enough, even though ANSI-standard bitfields are "ints", whether or not they are signed is also left up to the implementation. int myBit:1 may take on the values 0 and 1, or 0 and -1, depending on your compiler. Plain "int" doesn't necessarily mean "signed int" in the context of bitfields (unlike its normal meaning), and if you have a concern for portability or even just clarity, you might want to always specify "signed int" or "unsigned int" to be sure.

Children