
Padding is hard - spacey
http://dave.cheney.net/2015/10/09/padding-is-hard
======
zeveb
Given how much Go already does for one—and given the static nature of Go
binaries—is there any reason why the compiler shouldn't reorder structs so
that they take the least space possible?

I can see that that would prevent one from reliably dumping memory to disk and
then re-reading it, but It's hardly reliable to do that _anyway_. One should
be using an encoding anyway…

~~~
kibwen
If you're handing off a struct to C code, the order of your fields is going to
be significant. If the Go compiler began reordering struct fields as an
optimization, it would need to provide some way to disable that optimization
on a per-struct basis (and unless Go could automatically detect which structs
are crossing an FFI boundary, this optimization would need to be opt-in rather
than opt-out in order to avoid breaking existing code). As a precedent, Rust
deliberately does what you describe and reserves the right to reorder struct
fields (though AFAIK it's not actually exercising this right yet), and in
order to manually enforce a struct's layout you must tag it with the
#[repr(C)] attribute.

~~~
masklinn
Go struct memory layout is currently undefined[0], so you're already not
supposed to hand structs off to C, or to memcpy it to or from the wire. Unless
you're using cgo _maybe_ , I don't know if (or that) cgo provides any
guarantee.

[0]
[https://github.com/golang/go/issues/10014](https://github.com/golang/go/issues/10014)

~~~
kibwen
Is this mentioned in the spec anywhere? That piece of information was
precisely what I was looking for, but wasn't able to find.

~~~
masklinn
The spec doesn't define field ordering anywhere, which is why it's undefined.
Russ Cox commented on the bug I linked essentially confirming it:

> It seems fine to me for the spec not to guarantee anything about struct
> field order in memory. The spec doesn't operate at that level.

And while he adds

> That said, no Go compiler should probably ever reorder struct fields.

the final result is struct memory layout is unspecified and implementation-
dependent (essentially identical to repr(rust), as I understand it)

~~~
kibwen
The intent of a specification is to be explicit, and in doing so it's poor
form to say "this is undefined, so we're simply not going to mention it in the
spec at all". If it's undefined then the spec should say so, especially if the
alternative is for one to cast about in confusion until hopefully stumbling
across the relevant documentation in, of all places, the bug tracker.

------
ajkjk
If you're like me and had no idea what

_ struct{} // to prevent unkeyed literals

means, some explanation turns up here:
[https://groups.google.com/forum/#!topic/golang-
nuts/NSjVW82i...](https://groups.google.com/forum/#!topic/golang-
nuts/NSjVW82i0mY)

------
nkurz
The article mentions that the "Go spec says the address of a struct’s fields
must be naturally aligned", and seems to take for granted that is necessary
for speed. A separate question would be whether it actually helps performance.

For modern x64/x86 the answer seems be to "no":
[http://lemire.me/blog/2012/05/31/data-alignment-for-speed-
my...](http://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-
reality/)

Would it make sense for the Go spec to drop the alignment requirement? I'd
think that a smaller memory footprint would be the better choice, and I'd
think that interoperability would be better served by allowing arbitrary
alignments.

------
hoprocker
Side question: who is in that animated gif about a quarter of the way down the
page (fingers to temples, starbursts in background)? I see that around on dev
blogs quite a bit.

~~~
akira2501
[https://en.wikipedia.org/wiki/Tim_and_Eric_Awesome_Show,_Gre...](https://en.wikipedia.org/wiki/Tim_and_Eric_Awesome_Show,_Great_Job)!

It's not for everyone.

------
atria
So there isn't any equivalent to #pragma pack in Go? I'll stick with C/C++,
thanks.

~~~
ajkjk
Really, just like that? Seems irrational to discount every other argument
involved in such a decision.

