为何Win32 API系统调用中缓冲区需转为[1<<20]<type>数组？

Great question—this is a common pattern when bridging Go's type system with C-style Windows API strings, and it's totally reasonable to wonder why we're using such a huge array pointer. Let's break it down step by step:

First, What's This Code Actually Doing? #

Let's unpack the line you're looking at:

name := syscall.UTF16ToString((*[1 << 20]uint16)(unsafe.Pointer(s.ServiceName))[:]

1. unsafe.Pointer(s.ServiceName): Converts the raw Windows API pointer (pointing to the service name's UTF-16 string) into Go's unsafe.Pointer, which lets us work with foreign memory outside Go's type safety rules.
2. (*[1 << 20]uint16)(...): Reinterprets that raw pointer as the start of a fixed-size array of 1,048,576 uint16 elements (that's 1 million elements, or 2MB of memory total).
3. [:]: Turns that entire array into a []uint16 slice.
4. syscall.UTF16ToString(...): Reads the slice until it hits a null terminator (0), converting the UTF-16 sequence to a proper Go string.

Why Use a 1M-Size Array? #

Your confusion makes perfect sense—Windows service names aren't anywhere near 1M characters long (the actual maximum service name length is 256 UTF-16 characters, per Windows API docs). Here's why this trick works and why the size is chosen:

• Go's slice requirements: Go's syscall.UTF16ToString expects a []uint16 slice, not a raw pointer. A slice needs to know its length and capacity, but Windows API strings are null-terminated—we don't know the exact length upfront. By pretending the pointer points to a massive array, we create a slice with enough capacity to cover any plausible Windows service name (or even most other Windows API strings, for that matter).
• No actual memory allocation: Crucially, we're not allocating 1MB of memory here. This is just a type cast—we're telling Go's type system to treat the existing memory (pointed to by ServiceName) as if it's the start of a huge array. The slice doesn't own this memory; it's just a view into the foreign memory from the Windows API.
• Safety through over-provisioning: Using 1M is a conservative choice. It's way larger than any valid service name could ever be, so we never have to worry about the slice being too short to contain the full null-terminated string. syscall.UTF16ToString stops at the first null anyway, so it never reads past the actual service name data.

This Is a Common Interop Pattern #

You'll see this exact trick used everywhere in Go code that interacts with Windows APIs (or C libraries in general). For example, reading window titles, file paths, or registry values—anywhere you get a null-terminated UTF-16 pointer from the system, this pattern lets you safely convert it to a Go string without knowing the exact length upfront.

If you wanted to be more precise, you could use a smaller array (like [256]uint16 since service names max out at 256 chars), but using 1M is a lazy, safe choice that avoids having to look up every API's exact string length limit.

内容的提问来源于stack exchange，提问作者vlasta