P/Invoke Byte Padding x64

Question

4.00/5 (1 vote)

See more:

I'm modifying some earlier code to fully support 64bit OSes and wondered about the MMTIME struct (MSDN Link[^]).

C

typedef struct mmtime_tag {
  UINT wType;
  union {
    DWORD  ms;
    DWORD  sample;
    DWORD  cb;
    DWORD  ticks;
    struct {
      BYTE hour;
      BYTE min;
      BYTE sec;
      BYTE frame;
      BYTE fps;
      BYTE dummy;
      BYTE pad[2];
    } smpte;
    struct {
      DWORD songptrpos;
    } midi;
  } u;
} MMTIME, *PMMTIME, *LPMMTIME;

I have implemented this as below but wondered about the padding bytes specified by MS. As you can see it aligns to 4 byte blocks (32 bits) and I wondered would it be best to add an additional 4 bytes of padding, or does it not matter as only the lower byte of these 4 / 8 will ever be used?

C#

using System.Runtime.InteropServices;
using BYTE = System.Byte;
using DWORD = System.UInt32;
using UINT = System.UInt32;
using WORD = System.UInt16;
/// <summary>
/// Contains timing information for different types of multimedia data.
/// </summary>
[StructLayout(LayoutKind.Explicit)]
public struct MMTIME
{
    [FieldOffset(0)]
    public UINT wType;
    [FieldOffset(4)]
    public DWORD ms;
    [FieldOffset(4)]
    public DWORD sample;
    [FieldOffset(4)]
    public DWORD cb;
    [FieldOffset(4)]
    public DWORD ticks;
    [FieldOffset(4)]
    public BYTE hour;
    [FieldOffset(5)]
    public BYTE min;
    [FieldOffset(6)]
    public BYTE sec;
    [FieldOffset(7)]
    public BYTE frame;
    [FieldOffset(8)]
    public BYTE fps;
    [FieldOffset(9)]
    public BYTE dummy;
    [FieldOffset(10)]
    public WORD pad;
    [FieldOffset(4)]
    public DWORD songptrpos;
}

Posted 20-Apr-10 10:49am

DaveyM69

Updated 20-Apr-10 10:53am

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Luc Pattyn · Accepted Answer · 2010-04-21T11:22:00

Hi Dave,

that looks fine to me, it conforms to what http://pinvoke.net/[^] has, which is not a 100% guarantee.

All leaf elements are naturally aligned (i.e. assuming the origin is zero, all 4-byte quantities start at multiples of 4, etc), which is good for performance, and necessary on some processors (most RISC processors; not the IA-32 and IA-64 except for the SIMD units IIRC).

The overall size is 4+one of(4,4,4,4,8,4) hence 12; but then it does not have to be anything special; it is wise to make the overall length a multiple of the largest leaf element, which is OK here. So even when having an unpadded array of such things, all leaf elements are still naturally aligned.

FYI: there are some Win32 structs with length 6 (a short and an int), and API functions taking unpadded arrays of them. All that really matters is all parties agreeing, which means the field offsets, paddings, pragma's, compiler switches have to be compatible.

PS: what is keeping you from trying this? or should I ask: what is the real problem?

:)

Thanks Luc,

I don't currently have any of my gear hooked up to my 64-bit machine. I've run a few sample tests with SW based devices and it all seemed OK.

There are always cases in the real world where things don't behave as they do in the test environment (especially HW) and I just wanted to be sure that it wasn't probable that some 64bit driver for HW unknown to me would object to this not being a multiple of 8 bytes.

Thanks for your time :thumbsup: :beer: