Yes, that or just a link to the CR would be good. Thanks! - Rich
> On Oct 16, 2016, at 1:15 PM, Andy <asmalo...@gmail.com> wrote: > > Ah - ok. > > As I recall, I submitted a CR for it but Ian pointed out an edge case I > needed to handle. I never got to it because I changed direction and it didn't > seem like anyone else was interested in this modification at the time. > > I can dig out the diffs from my previous attempt if that would help get you > started - let me know. > > --- > Andy Maloney // https://asmaloney.com <https://asmaloney.com/> > twitter ~ @asmaloney <https://twitter.com/asmaloney> > > On Sun, Oct 16, 2016 at 3:07 PM, Richard Wilkes <wil...@me.com > <mailto:wil...@me.com>> wrote: > Hi, Andy. > > Thanks for replying. No, I was interested in the change to allow a struct > defined in Go to be passed to C, even if it only supported basic types. > Sounds like that part never made it in — certainly Go 1.7.1 doesn’t seem to > allow me to do such things, which is unfortunate. > > - Rich > > > >> On Oct 16, 2016, at 10:23 AM, Andy <asmalo...@gmail.com >> <mailto:asmalo...@gmail.com>> wrote: >> >> Richard: >> >> If you're asking about: >> >> "cmd/cgo: annotate named return struct members in comments " >> https://go-review.googlesource.com/#/c/13061/ >> <https://go-review.googlesource.com/#/c/13061/> >> >> It looks like that was merged at some point, but I'm not sure. >> >> I abandoned my experiments with go/cgo when some of the limitations became >> clear. I wouldn't ultimately be able to do what I'd wanted to with it. >> >> --- >> Andy Maloney // https://asmaloney.com <https://asmaloney.com/> >> twitter ~ @asmaloney <https://twitter.com/asmaloney> >> >> On Sun, Oct 16, 2016 at 12:51 PM, Richard Wilkes <raw.softw...@gmail.com >> <mailto:raw.softw...@gmail.com>> wrote: >> Andy, >> >> What's the status of getting this change into Go? I have an issue that could >> benefit from this particular support and was curious if/when I'd be able to >> use it. >> >> Thanks! >> >> - Rich >> >> >> On Sunday, August 9, 2015 at 4:24:52 PM UTC-7, Andy Maloney wrote: >> I imagine it will take some back-and-forth with you to get it into shape - >> make sure it's idiomatic and fits with the current structure - so I'll wait >> until after 1.5 is out. >> >> It requires changes I put in another CL >> (https://go-review.googlesource.com/#/c/13061/ >> <https://go-review.googlesource.com/#/c/13061/> ). How do I handle that >> when I want to create a new CL? Just branch off that one? Or do just wait >> until the other one is accepted and merged? >> >> On Sunday, August 9, 2015 at 5:04:03 PM UTC-4, Ian Lance Taylor wrote: >> On Sun, Aug 9, 2015 at 1:49 PM, Andy Maloney <asma...@gmail.com <>> wrote: >> > On Sunday, August 9, 2015 at 4:05:34 PM UTC-4, Ian Lance Taylor wrote: >> >> >> >> On Sun, Aug 9, 2015 at 11:47 AM, Andy Maloney <asma...@gmail.com <>> >> >> wrote: >> >> > >> >> > after all the Decls are added to the Package in Record() (in main.go), >> >> > call >> >> > a function which looks at each of the exported functions and uses the >> >> > Decls >> >> > to create a map to store some information about struct parameters & >> >> > results >> >> > in cgoType(), use the map that was just created to lookup the name of >> >> > the >> >> > struct and its size (which we calculated and stored in the map) and, if >> >> > we >> >> > find it, return it >> >> > at the end of writeExportHeader(), write out typedefs for each of the >> >> > structs in the map >> >> >> >> I'm not quite sure what you mean here. It seems to me that you can >> >> treat any struct used by an exported function as though the Go code >> >> said "C.struct_foo". That should define in Go like other cgo >> >> structs. >> > >> > I'm not seeing how to do this, but does that mean from my example above >> > I'd >> > end up with this in the header: >> > >> > typedef struct { >> > GoInt r0; >> > GoString r1; >> > } struct_Bar; >> > >> > >> > extern struct_Bar Foo(); >> > >> > (And I'd lose the names of the members like I currently do in the return >> > structs?) >> >> Sorry, I was confused. You have structs defined in Go, and you need >> them to be defined in C. For some reason I was thinking about this >> the other way around. >> >> Sure, something like what you described sounds reasonable. >> >> >> >> > Right now I just look at structs, but it would make sense to me that if >> >> > you >> >> > declare >> >> > type Foo int >> >> > and you use it as a result to a function we should see >> >> > typedef GoInt Foo; >> >> > in the header file. Would that make sense to add too? >> >> >> >> I doubt it. C typedefs are not Go typedefs. Go's types are much >> >> stricter. I expect that changing this would break currently working >> >> code. >> > >> > >> > Wouldn't this just be preserving the name of the type in the C code? >> > Whether you call it a GoInt or a Foo in this case should be the same - >> > it's >> > just an alias in C. Not sure I see how that would break anything. >> >> Same confusion on my part. I'm not sure the typedef names help much >> but I suppose it is fine. >> >> 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.
