Here is the original CR:
https://go-review.googlesource.com/#/c/14060/
Locally I'd fixed the tests and added one for the unnamed struct case Ian
pointed out - but I never checked this in (see attached diff).
So after this is brought in line with the current source I think it just
needs to be modified to handle unnamed structs.
---
Andy Maloney // https://asmaloney.com
twitter ~ @asmaloney <https://twitter.com/asmaloney>
On Sun, Oct 16, 2016 at 4:17 PM, Richard Wilkes <wil...@me.com> wrote:
> 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
> twitter ~ @asmaloney <https://twitter.com/asmaloney>
>
>
> On Sun, Oct 16, 2016 at 3:07 PM, Richard Wilkes <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> wrote:
>>
>> Richard:
>>
>> If you're asking about:
>>
>> "cmd/cgo: annotate named return struct members in comments "
>> 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
>> twitter ~ @asmaloney <https://twitter.com/asmaloney>
>>
>>
>> On Sun, Oct 16, 2016 at 12:51 PM, Richard Wilkes <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.googlesourc
>>>> e.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.
diff --git a/misc/cgo/testcarchive/main.c b/misc/cgo/testcarchive/main.c
index 7863dd7..0cc366c 100644
--- a/misc/cgo/testcarchive/main.c
+++ b/misc/cgo/testcarchive/main.c
@@ -28,16 +28,16 @@ int main(void) {
return 2;
}
- AlignedStruct as = CheckResultAlignedStruct();
+ AlignedStruct as = CheckResultAlignedStruct();
- if (as.Foo != 42 || strncmp( as.Bar.p, "bar", as.Bar.n )) {
+ if (as.Foo != 42 || strncmp(as.Bar.p, "bar", as.Bar.n) != 0) {
fprintf(stderr, "ERROR: aligned result struct invalid\n");
return 2;
}
CheckParamAlignedStruct(as);
- UnalignedStruct us1;
+ UnalignedStruct us1;
us1.Foo = 42;
us1.Baz = 1;
us1.Bar.p = "bar";
@@ -46,13 +46,15 @@ int main(void) {
CheckParamUnalignedStruct(us1);
- UnalignedStruct us2 = CheckResultUnalignedStruct();
+ UnalignedStruct us2 = CheckResultUnalignedStruct();
- if (us2.Foo != 42 || us2.Baz != 1 || strncmp( us2.Bar.p, "bar",
us2.Bar.n ) || us2.Qux != 128) {
+ if (us2.Foo != 42 || us2.Baz != 1 || strncmp(us2.Bar.p, "bar",
us2.Bar.n) != 0 || us2.Qux != 128) {
fprintf(stderr, "ERROR: unaligned result struct invalid\n");
return 2;
}
+ CheckResultUnnamedStruct();
+
CheckArgs();
fprintf(stderr, "PASS\n");
diff --git a/misc/cgo/testcarchive/src/libgo/libgo.go
b/misc/cgo/testcarchive/src/libgo/libgo.go
index dbd151d..0397702 100644
--- a/misc/cgo/testcarchive/src/libgo/libgo.go
+++ b/misc/cgo/testcarchive/src/libgo/libgo.go
@@ -93,3 +93,8 @@ func CheckParamUnalignedStruct(u UnalignedStruct) {
func CheckResultUnalignedStruct() UnalignedStruct {
return UnalignedStruct{42, true, "bar", 128}
}
+
+//export CheckResultUnnamedStruct
+func CheckResultUnnamedStruct() struct{ i, j int } {
+ return struct{ i, j int }{1, 2}
+}
