P/调用字节填充x64 [英] P/Invoke Byte Padding x64

问题描述

我正在修改一些较早的代码以完全支持64位操作系统，并想知道MMTIME结构( ^ ]).

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

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;

我已经实现了以下内容，但想知道MS指定的填充字节.如您所见，它与4个字节的块(32位)对齐，我想知道最好再添加4个字节的填充，还是没关系，因为仅会使用这4/8的较低字节?

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?

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;
}

推荐答案

戴夫，

对我来说很好，它符合 http://pinvoke.net/ [ ^ ]拥有，但不是100％保证.

所有叶子元素都是自然对齐的(即假设原点为零，所有4字节的数量以4的倍数开始，依此类推)，这对性能有利，并且在某些处理器(大多数RISC处理器；不是IA-32和IA-32)上是必需的IA-64(SIMD单元IIRC除外).

整体大小为4+one of(4,4,4,4,8,4)，因此为12；但这并不一定要特别.明智的做法是使总长度为最大叶元素的倍数，这在这里是可以的.因此，即使具有未填充的此类数组，所有叶子元素仍会自然对齐.

仅供参考:有些Win32结构的长度为6(短整数)，API函数采用未填充的数组.真正重要的是各方都同意，这意味着字段偏移量，填充，编译指示和编译器开关必须兼容.

PS:是什么让您无法尝试?还是我问:真正的问题是什么?

:)

感谢Luc，

我目前还没有将自己的设备挂接到64位计算机上.我已经对基于SW的设备进行了一些示例测试，一切似乎都很好.

在现实世界中，总有一些情况不能像在测试环境中那样(特别是硬件)，并且我只是想确保我可能不知道某些64位的硬件驱动程序不会被我发现反对这不是8字节的倍数.

谢谢您的时间:thumbsup::beer:

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:

这篇关于P/调用字节填充x64的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！