Header file won't have padding / alignment info. That would be a compiler setting on the C side that is using the header. So the programmer needs to setup C compiler in a way that is compatible with the go compiler. How would he know how to set it up? Do we just assume defaults are the same between Go and C?
Typical alignment options are listed for various data types here: https://en.wikipedia.org/wiki/Data_structure_alignment Thanks, Suavi On Mon, Sep 19, 2016 at 7:58 AM, Ian Lance Taylor <i...@golang.org> wrote: > On Sun, Sep 18, 2016 at 11:10 PM, <dem...@gmail.com> wrote: > > Is there any update to alignment/padding for structs now that we can > write > > .so files that can be called by C programs? We would have to know it to > tell > > the C compiler what to expect from go side imho. > > When you use //export with cmd/cgo you will get a header file that > your C code can #include. See > https://golang.org/cmd/cgo/#hdr-C_references_to_Go . > > Ian > > > > On Thursday, April 5, 2012 at 9:10:48 PM UTC-7, Kyle Lemons wrote: > >> > >> On Thu, Apr 5, 2012 at 7:11 AM, LRN <lrn...@gmail.com> wrote: > >>> > >>> Related question: > >>> If alignment and padding is platform dependent, how do you write and > read > >>> structs to/from a socket? > >> > >> > >> The solution is to not write platform dependent code. The related topic > >> of byte ordering and platform independence is covered in this blog post. > >> The gob package (incidentally, if I'm not mistaken, also written by the > >> author of that blog post), is a performant binary encoding scheme that > will > >> work from and to any platform that supports go. > >> > >>> > >>> For example, in C it is not uncommon to declare a struct, initialize > its > >>> fields with values (converted to big-endian format), then write it > into a > >>> socket in one call. > >>> The receiver will, again, read the struct from a socket in one call, > then > >>> will do big-endian-to-native format conversion on each field where it > is > >>> applicable - and will get the same struct the sender had. > >>> This only works when definitions of the struct on both the sender and > the > >>> receiver are aligned in the same way (usually - 1-byte aligned). > >>> > >>> I've encountered this problem recently, which is why i'm asking. > >>> > >>> Also, MSVC uses a padding algorithm different from the one gcc has, > which > >>> is why there's a -mms-bitfields option in gcc. It forces gcc to use > >>> MSVC-style padding, which is required if the caller wants to pass > certain > >>> structs to W32 API. > >>> How will that work in Go? (h-m-m-m...i can probably infer that from W32 > >>> port of Go by reading its source code...) > >> > >> > > -- > > You received this message because you are subscribed to the Google Groups > > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to golang-nuts+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
