Yes, so what you are describing to me needs to be told to the C compiler users in a formal way so that they make sure their alignment is the same as Go. Thanks.
On Mon, Sep 19, 2016 at 2:27 PM, Ian Lance Taylor <i...@golang.org> wrote: > On Mon, Sep 19, 2016 at 2:08 PM, Ali Demir <dem...@gmail.com> wrote: > > Packing option is explicitly specified for VC++: > > > > https://msdn.microsoft.com/en-us/library/xh3e3fd0.aspx > > > > The user needs to make sure whatever they pick (or default) in their > project > > matches what Go compiler used. So it may help to specify what go > compiler is > > using. > > There is no answer to that question. The Go compiler is not running > the C compiler. > > In general the Go compiler expects fields to be aligned to their size. > That is, a four byte field is aligned to a four byte boundary, and an > eight byte field is aligned to an eight byte boundary. As I said > earlier, the compiler emits padding fields so that everything will > work if the C compiler uses a smaller alignment. However, things will > fail if the C compiler uses a larger alignment. I'm not aware of any > such C compiler, but I guess it wouldn't shock me. > > Ian > > > On Mon, Sep 19, 2016 at 10:00 AM, Ian Lance Taylor <i...@golang.org> > wrote: > >> > >> On Mon, Sep 19, 2016 at 8:50 AM, Ali Demir <dem...@gmail.com> wrote: > >> > 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? > >> > >> The cgo tool will generate padding fields as needed to ensure that the > >> fields are aligned as expected. > >> > >> It's true that the cgo tool does assume that it knows the alignment > >> requirements of the basic types. These requirements are not normally > >> changed by compiler options. The alignment requirements of unusual > >> types, such as processor-specific vector types, are not relevant, > >> since Go can't represent them and they will therefore never appear in > >> the Go/C interface. > >> > >> Do you have a specific concern, or is this purely abstract? > >> > >> Ian > > > > > -- 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.
