Structure and Union Size Issue

Hi Experts,

I need a structure with 3 byte size and what am getting is 4 byte due to the usage of bitfields.

I need a structure member with exact bits and so I used bitfields. But it is reflecting on the size of the structure.

This is my structure: Can anyone please guide me how to get the structure size as 3 byte.

struct vlan_un_struct {
u32 noname : 20;
u32 vlan_pri : 4;
} ; /* struct vlan_un_struct [3 byte] */

Regards,
Janaki.P

I need to use this structure in Windows Visual Studio Compiler.

In GCC Compiler,the structure was packed using attribute((packed)) and I got it as 3byte.

How can i achieve such packing in Visual Studio??‘’

Please anyone guide me.

https://msdn.microsoft.com/en-us/library/2e70t5y1.aspx

Sent from Mailhttps: for Windows 10

From: xxxxx@gmail.commailto:xxxxx
Sent: November 23, 2016 5:08 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Structure and Union Size Issue

I need to use this structure in Windows Visual Studio Compiler.

In GCC Compiler,the structure was packed using attribute ((packed)) and I got it as 3byte.

How can i achieve such packing in Visual Studio??‘’

Please anyone guide me.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>

#pragma pack(1)

On Wed, Nov 23, 2016 at 8:20 AM Marion Bond wrote:

> https://msdn.microsoft.com/en-us/library/2e70t5y1.aspx
>
>
>
>
>
> Sent from Mail https: for
> Windows 10
>
>
>
> *From: *xxxxx@gmail.com
> *Sent: *November 23, 2016 5:08 AM
> *To: *Windows System Software Devs Interest List
> *Subject: *RE:[ntdev] Structure and Union Size Issue
>
>
> I need to use this structure in Windows Visual Studio Compiler.
>
> In GCC Compiler,the structure was packed using
> attribute ((packed)) and I got it as 3byte.
>
> How can i achieve such packing in Visual Studio??‘’
>
> Please anyone guide me.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></https:>

@Jamey . Thanks for your reply.

Actually, I tried this #pragma pack(1) already and I got the size as 4byte.

Still waiting for luck.

You will be waiting a very long time then.

Your datatype in the union is u32 which I presume means some sort of unsigned 32-bit type. The compiler is obligated by that declaration to allocate 32-bits and align it appropriately. Just because you only use 24 of those bits does not mean the other 8 are not present.

The clever trick / extension from GCC is not portable (or standard) C.

Since you seem to be working on a network driver as this looks quite a bit like a VLAN/QOS tag my suggestion to you is to look at how NDIS samples handle this.

The short answer to your question is this:

Serialize and Deserialize the octets from your wire format as UCHAR (or u8, or whatever your byte type de jour is).

Manually code the masking and (as necessary) nibble/byte swapping to match the wire format to host format.

There is no free lunch in wire-format conversion if you want it to be done correctly. The GCC code will break on a machine with different Endianess.

Good Luck,
Dave Cattley

Let me add 5 cents from my side.

As already said Dave, bit-field implementation is completely compiler
defined, that’s why it’s not portable and not recommended to use.

Main reason why you are getting size of the bit-field 4 instead of
desirable 3 is alignment of given structure in the memory.
By definition bit-fields have integral type that means the size of
structure is depends on the particular machine (32/64-bit).
Of course you can change the type of alignment but you can’t to set
alignment equal 3.

If you want to get desirable structure size you can use normal structure
definition instead of bit-field, namely:

#pragma pack(1)

struct t_test
{
unsigned short a;
char b;
};

For that structure you’ll get the desirable size equal 3.

Best Regards,
Dmitry

On Wed, Nov 23, 2016 at 3:02 PM, wrote:

> @Jamey . Thanks for your reply.
>
> Actually, I tried this #pragma pack(1) already and I got the size as
> 4byte.
>
> Still waiting for luck.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

xxxxx@gmail.com wrote:

I need a structure with 3 byte size and what am getting is 4 byte due to the usage of bitfields.

I need a structure member with exact bits and so I used bitfields. But it is reflecting on the size of the structure.

This is my structure: Can anyone please guide me how to get the structure size as 3 byte.

struct vlan_un_struct {
u32 noname : 20;
u32 vlan_pri : 4;
} ; /* struct vlan_un_struct [3 byte] */

There is no way to do that. In order to have a single field of 20 bits,
you need to make the field type 32 bits wide, and that means the
structure is going to be 32 bits. You will have to declare an unsigned
char [3] and use macros to extract the fields.

Bitfields are problematic under the best of circumstances. Remember
that the standard does not dictate in what order the fields are laid
out. A different compiler might produce a different layout.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.