Click here to Skip to main content
15,844,477 members
Please Sign up or sign in to vote.
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
Updated 20-Apr-10 11:53am
v2

1 solution

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:
 
Share this answer
 
v2

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900