code review 11377043: cmd/cgo: Fix issue with cgo cdefs

cmd/cgo: Fix issue with cgo cdefs

The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
properly translating the Go array type to a C array type when an
asterisk follows the [] in the array type declaration (it is perfectly
legal to put the asterisk on either side of the [] in go syntax,
depending on how you set up your pointers).

That said, the cdefs tool is only designed to translate from Go types
generated using the cgo *godefs* tool -- where the godefs tool is
designed to translate gcc-style C types into Go types. In essence, the
cdefs tool translates from gcc-style C types to Go types (via the godefs
tool), then back to kenc-style C types. Because of this, cdefs does not
need to know how to translate arbitraty Go types into C, just the ones
produced by godefs.

The problem is that during this translation process, the logic is
slightly wrong when going from (e.g.):

char *array[10];
to:
array [10]*int8;
back to:
int8 *array[10];

In the current implementation of cdecl(), the translation from the Go
type declaration back to the kenc-style declaration looks for Go
types of the form:

name *[]type;
rather than the actual generated Go type declaration of:
name []*type;

Both are valid Go syntax, with slightly different semantics, but the
latter is the only one that can ever be generated by the godefs tools.
(The semantics of the former are not directly expressible in a
single C statement -- you would have to have to first typedef the array
type, then declare a pointer to that typedef'd type in a separate
statement).

This commit changes the logic of cdecl() to look properly for, and
translate, Go type declarations of the form:
name []*type;

Additionally, the original implementation only allowed for a single
asterisk and a single sized aray (i.e. only a single level of pointer
indirection, and only one set of []) on the type, whereas the patched
version allows for an arbitrary number of both.

Tests are included in misc/cgo/testcdefs and the all.bash script has been
updated to account for these.

[klueska, 2013-07-16 18:52:29]

Hello golang-dev@googlegroups.com (cc: iant@golang.org),

I'd like you to review this change to
https://code.google.com/p/go

[klueska, 2013-07-16 20:37:56]

On 2013/07/16 18:52:29, klueska wrote:
> Hello mailto:golang-dev@googlegroups.com (cc: mailto:iant@golang.org),
> 
> I'd like you to review this change to
> https://code.google.com/p/go

Additionally, we should be looping over all the [x] elements as well in case of
multi-dimensional arrays. Update submitted.

Kevin

[bradfitz, 2013-07-17 00:18:35]

I guess cgo has no tests?



On Wed, Jul 17, 2013 at 4:52 AM, <klueska@gmail.com> wrote:

> Reviewers: golang-dev1,
>
> Message:
> Hello golang-dev@googlegroups.com (cc: iant@golang.org),
>
>
> I'd like you to review this change to
> https://code.google.com/p/go
>
>
> Description:
> cmd/cgo: Fix issue with cgo cdefs
>
> The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
> properly translating the Go array type to a C array type when an
> asterisk follows the [] in the array type declaration (it is perfectly
> legal to put the asterisk on either side of the [] in go syntax,
> depending on how you set up your pointers).
>
> That said, the cdefs tool is only designed to translate from Go types
> generated using the cgo *godefs* tool -- where the godefs tool is
> designed to translate gcc-style C types into Go types. In essence, the
> cdefs tool translates from gcc-style C types to Go types (via the godefs
> tool), then back to kenc-style C types. Because of this, cdefs does not
> need to know how to translate arbitraty Go types into C, just the ones
> produced by godefs.
>
> The problem is that during this translation process, the logic is
> slightly wrong when going from (e.g.):
>
> char *array[10];
> to:
> array [10]*int8;
> back to:
> int8 *array[10];
>
> In the current implementation of cdecl(), the translation from the Go
> type declaration back to the kenc-style declaration looks for Go
> types of the form:
>
> name *[]type;
> rather than the actual generated Go type declaration of:
> name []*type;
>
> Both are valid Go syntax, with slightly different semantics, but the
> latter is the only one that can ever be generated by the godefs tools.
> (The semantics of the former are not directly expressible in a
> single C statement -- you would have to have to first typedef the array
> type, then declare a pointer to that typedef'd type in a separate
> statement).
>
> This commit changes the logic of cdecl() to look properly for, and
> translate, Go type declarations of the form:
> name []*type;
>
> Additionally, the original implementation only allowed for a single
> asterisk (i.e. only a single level of pointer indirection) on the type,
> whereas the patched version allows for an arbitrary number of
> asterisks.
>
> Please review this at
https://codereview.appspot.**com/11377043/<https://codereview.appspot.com/113...
>
> Affected files:
>   M src/cmd/cgo/godefs.go
>
>
> Index: src/cmd/cgo/godefs.go
> ==============================**==============================**=======
> --- a/src/cmd/cgo/godefs.go
> +++ b/src/cmd/cgo/godefs.go
> @@ -261,17 +261,17 @@
>         if strings.HasPrefix(typ, "*[0]") {
>                 typ = "*void"
>         }
> -       // X *byte -> *X byte
> -       if strings.HasPrefix(typ, "*") {
> -               name = "*" + name
> -               typ = typ[1:]
> -       }
>         // X [4]byte -> X[4] byte
>         if strings.HasPrefix(typ, "[") {
>                 i := strings.Index(typ, "]") + 1
>                 name = name + typ[:i]
>                 typ = typ[i:]
>         }
> +       // X *byte -> *X byte
> +       for strings.HasPrefix(typ, "*") {
> +               name = "*" + name
> +               typ = typ[1:]
> +       }
>         // X T -> T X
>         // Handle the special case: 'unsafe.Pointer' is 'void *'
>         if typ == "unsafe.Pointer" {
>
>
>
> --
>
> ---You received this message because you are subscribed to the Google
> Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
golang-dev+unsubscribe@**googlegroups.com<golang-dev%2Bunsubscribe@googlegrou...
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o...
> .
>
>
>

[dave_cheney.net, 2013-07-17 00:48:33]

I thought we put the tests in misc/cgo/test

On Wed, Jul 17, 2013 at 10:18 AM, Brad Fitzpatrick <bradfitz@golang.org> wrote:
> I guess cgo has no tests?
>
>
>
> On Wed, Jul 17, 2013 at 4:52 AM, <klueska@gmail.com> wrote:
>>
>> Reviewers: golang-dev1,
>>
>> Message:
>> Hello golang-dev@googlegroups.com (cc: iant@golang.org),
>>
>>
>> I'd like you to review this change to
>> https://code.google.com/p/go
>>
>>
>> Description:
>> cmd/cgo: Fix issue with cgo cdefs
>>
>> The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
>> properly translating the Go array type to a C array type when an
>> asterisk follows the [] in the array type declaration (it is perfectly
>> legal to put the asterisk on either side of the [] in go syntax,
>> depending on how you set up your pointers).
>>
>> That said, the cdefs tool is only designed to translate from Go types
>> generated using the cgo *godefs* tool -- where the godefs tool is
>> designed to translate gcc-style C types into Go types. In essence, the
>> cdefs tool translates from gcc-style C types to Go types (via the godefs
>> tool), then back to kenc-style C types. Because of this, cdefs does not
>> need to know how to translate arbitraty Go types into C, just the ones
>> produced by godefs.
>>
>> The problem is that during this translation process, the logic is
>> slightly wrong when going from (e.g.):
>>
>> char *array[10];
>> to:
>> array [10]*int8;
>> back to:
>> int8 *array[10];
>>
>> In the current implementation of cdecl(), the translation from the Go
>> type declaration back to the kenc-style declaration looks for Go
>> types of the form:
>>
>> name *[]type;
>> rather than the actual generated Go type declaration of:
>> name []*type;
>>
>> Both are valid Go syntax, with slightly different semantics, but the
>> latter is the only one that can ever be generated by the godefs tools.
>> (The semantics of the former are not directly expressible in a
>> single C statement -- you would have to have to first typedef the array
>> type, then declare a pointer to that typedef'd type in a separate
>> statement).
>>
>> This commit changes the logic of cdecl() to look properly for, and
>> translate, Go type declarations of the form:
>> name []*type;
>>
>> Additionally, the original implementation only allowed for a single
>> asterisk (i.e. only a single level of pointer indirection) on the type,
>> whereas the patched version allows for an arbitrary number of
>> asterisks.
>>
>> Please review this at https://codereview.appspot.com/11377043/
>>
>> Affected files:
>>   M src/cmd/cgo/godefs.go
>>
>>
>> Index: src/cmd/cgo/godefs.go
>> ===================================================================
>> --- a/src/cmd/cgo/godefs.go
>> +++ b/src/cmd/cgo/godefs.go
>> @@ -261,17 +261,17 @@
>>         if strings.HasPrefix(typ, "*[0]") {
>>                 typ = "*void"
>>         }
>> -       // X *byte -> *X byte
>> -       if strings.HasPrefix(typ, "*") {
>> -               name = "*" + name
>> -               typ = typ[1:]
>> -       }
>>         // X [4]byte -> X[4] byte
>>         if strings.HasPrefix(typ, "[") {
>>                 i := strings.Index(typ, "]") + 1
>>                 name = name + typ[:i]
>>                 typ = typ[i:]
>>         }
>> +       // X *byte -> *X byte
>> +       for strings.HasPrefix(typ, "*") {
>> +               name = "*" + name
>> +               typ = typ[1:]
>> +       }
>>         // X T -> T X
>>         // Handle the special case: 'unsafe.Pointer' is 'void *'
>>         if typ == "unsafe.Pointer" {
>>
>>
>>
>> --
>>
>> ---You received this message because you are subscribed to the Google
>> Groups "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[klueska, 2013-07-17 00:52:13]

There appear to be cgo tests in there, but nothing that tests the
output of the cdefs flag specifically
(i.e. running 'grep -R cdefs ../misc/cgo/test/' returns nothing).

Kevin

On Tue, Jul 16, 2013 at 5:48 PM, Dave Cheney <dave@cheney.net> wrote:
> I thought we put the tests in misc/cgo/test
>
> On Wed, Jul 17, 2013 at 10:18 AM, Brad Fitzpatrick <bradfitz@golang.org>
wrote:
>> I guess cgo has no tests?
>>
>>
>>
>> On Wed, Jul 17, 2013 at 4:52 AM, <klueska@gmail.com> wrote:
>>>
>>> Reviewers: golang-dev1,
>>>
>>> Message:
>>> Hello golang-dev@googlegroups.com (cc: iant@golang.org),
>>>
>>>
>>> I'd like you to review this change to
>>> https://code.google.com/p/go
>>>
>>>
>>> Description:
>>> cmd/cgo: Fix issue with cgo cdefs
>>>
>>> The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
>>> properly translating the Go array type to a C array type when an
>>> asterisk follows the [] in the array type declaration (it is perfectly
>>> legal to put the asterisk on either side of the [] in go syntax,
>>> depending on how you set up your pointers).
>>>
>>> That said, the cdefs tool is only designed to translate from Go types
>>> generated using the cgo *godefs* tool -- where the godefs tool is
>>> designed to translate gcc-style C types into Go types. In essence, the
>>> cdefs tool translates from gcc-style C types to Go types (via the godefs
>>> tool), then back to kenc-style C types. Because of this, cdefs does not
>>> need to know how to translate arbitraty Go types into C, just the ones
>>> produced by godefs.
>>>
>>> The problem is that during this translation process, the logic is
>>> slightly wrong when going from (e.g.):
>>>
>>> char *array[10];
>>> to:
>>> array [10]*int8;
>>> back to:
>>> int8 *array[10];
>>>
>>> In the current implementation of cdecl(), the translation from the Go
>>> type declaration back to the kenc-style declaration looks for Go
>>> types of the form:
>>>
>>> name *[]type;
>>> rather than the actual generated Go type declaration of:
>>> name []*type;
>>>
>>> Both are valid Go syntax, with slightly different semantics, but the
>>> latter is the only one that can ever be generated by the godefs tools.
>>> (The semantics of the former are not directly expressible in a
>>> single C statement -- you would have to have to first typedef the array
>>> type, then declare a pointer to that typedef'd type in a separate
>>> statement).
>>>
>>> This commit changes the logic of cdecl() to look properly for, and
>>> translate, Go type declarations of the form:
>>> name []*type;
>>>
>>> Additionally, the original implementation only allowed for a single
>>> asterisk (i.e. only a single level of pointer indirection) on the type,
>>> whereas the patched version allows for an arbitrary number of
>>> asterisks.
>>>
>>> Please review this at https://codereview.appspot.com/11377043/
>>>
>>> Affected files:
>>>   M src/cmd/cgo/godefs.go
>>>
>>>
>>> Index: src/cmd/cgo/godefs.go
>>> ===================================================================
>>> --- a/src/cmd/cgo/godefs.go
>>> +++ b/src/cmd/cgo/godefs.go
>>> @@ -261,17 +261,17 @@
>>>         if strings.HasPrefix(typ, "*[0]") {
>>>                 typ = "*void"
>>>         }
>>> -       // X *byte -> *X byte
>>> -       if strings.HasPrefix(typ, "*") {
>>> -               name = "*" + name
>>> -               typ = typ[1:]
>>> -       }
>>>         // X [4]byte -> X[4] byte
>>>         if strings.HasPrefix(typ, "[") {
>>>                 i := strings.Index(typ, "]") + 1
>>>                 name = name + typ[:i]
>>>                 typ = typ[i:]
>>>         }
>>> +       // X *byte -> *X byte
>>> +       for strings.HasPrefix(typ, "*") {
>>> +               name = "*" + name
>>> +               typ = typ[1:]
>>> +       }
>>>         // X T -> T X
>>>         // Handle the special case: 'unsafe.Pointer' is 'void *'
>>>         if typ == "unsafe.Pointer" {
>>>
>>>
>>>
>>> --
>>>
>>> ---You received this message because you are subscribed to the Google
>>> Groups "golang-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to golang-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>



-- 
~Kevin

[klueska, 2013-07-17 21:28:23]

I've added some tests in misc/cgo/testcdefs that test this bug and verify it is
fixed in the patch. I couldn't just add a new test case under misc/cgo/test
because I need to manually run cgo with the -cdefs option and then test the
output of that command by piping it to a file and including it in a c file
before building.

I tried to follow the style that the misc/cgo/testso folder uses in running a
custom test script.  That said, I'm a first time contributor, so I may have done
something non-conventional in terms of how things are normally done in this
project.  If so, let me know, and I'm more than willing to fix it up.

Kevin

On 2013/07/17 00:52:13, klueska wrote:
> There appear to be cgo tests in there, but nothing that tests the
> output of the cdefs flag specifically
> (i.e. running 'grep -R cdefs ../misc/cgo/test/' returns nothing).
> 
> Kevin
> 
> On Tue, Jul 16, 2013 at 5:48 PM, Dave Cheney <mailto:dave@cheney.net> wrote:
> > I thought we put the tests in misc/cgo/test
> >
> > On Wed, Jul 17, 2013 at 10:18 AM, Brad Fitzpatrick
<mailto:bradfitz@golang.org>
> wrote:
> >> I guess cgo has no tests?
> >>
> >>
> >>
> >> On Wed, Jul 17, 2013 at 4:52 AM, <mailto:klueska@gmail.com> wrote:
> >>>
> >>> Reviewers: golang-dev1,
> >>>
> >>> Message:
> >>> Hello mailto:golang-dev@googlegroups.com (cc: mailto:iant@golang.org),
> >>>
> >>>
> >>> I'd like you to review this change to
> >>> https://code.google.com/p/go
> >>>
> >>>
> >>> Description:
> >>> cmd/cgo: Fix issue with cgo cdefs
> >>>
> >>> The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
> >>> properly translating the Go array type to a C array type when an
> >>> asterisk follows the [] in the array type declaration (it is perfectly
> >>> legal to put the asterisk on either side of the [] in go syntax,
> >>> depending on how you set up your pointers).
> >>>
> >>> That said, the cdefs tool is only designed to translate from Go types
> >>> generated using the cgo *godefs* tool -- where the godefs tool is
> >>> designed to translate gcc-style C types into Go types. In essence, the
> >>> cdefs tool translates from gcc-style C types to Go types (via the godefs
> >>> tool), then back to kenc-style C types. Because of this, cdefs does not
> >>> need to know how to translate arbitraty Go types into C, just the ones
> >>> produced by godefs.
> >>>
> >>> The problem is that during this translation process, the logic is
> >>> slightly wrong when going from (e.g.):
> >>>
> >>> char *array[10];
> >>> to:
> >>> array [10]*int8;
> >>> back to:
> >>> int8 *array[10];
> >>>
> >>> In the current implementation of cdecl(), the translation from the Go
> >>> type declaration back to the kenc-style declaration looks for Go
> >>> types of the form:
> >>>
> >>> name *[]type;
> >>> rather than the actual generated Go type declaration of:
> >>> name []*type;
> >>>
> >>> Both are valid Go syntax, with slightly different semantics, but the
> >>> latter is the only one that can ever be generated by the godefs tools.
> >>> (The semantics of the former are not directly expressible in a
> >>> single C statement -- you would have to have to first typedef the array
> >>> type, then declare a pointer to that typedef'd type in a separate
> >>> statement).
> >>>
> >>> This commit changes the logic of cdecl() to look properly for, and
> >>> translate, Go type declarations of the form:
> >>> name []*type;
> >>>
> >>> Additionally, the original implementation only allowed for a single
> >>> asterisk (i.e. only a single level of pointer indirection) on the type,
> >>> whereas the patched version allows for an arbitrary number of
> >>> asterisks.
> >>>
> >>> Please review this at https://codereview.appspot.com/11377043/
> >>>
> >>> Affected files:
> >>>   M src/cmd/cgo/godefs.go
> >>>
> >>>
> >>> Index: src/cmd/cgo/godefs.go
> >>> ===================================================================
> >>> --- a/src/cmd/cgo/godefs.go
> >>> +++ b/src/cmd/cgo/godefs.go
> >>> @@ -261,17 +261,17 @@
> >>>         if strings.HasPrefix(typ, "*[0]") {
> >>>                 typ = "*void"
> >>>         }
> >>> -       // X *byte -> *X byte
> >>> -       if strings.HasPrefix(typ, "*") {
> >>> -               name = "*" + name
> >>> -               typ = typ[1:]
> >>> -       }
> >>>         // X [4]byte -> X[4] byte
> >>>         if strings.HasPrefix(typ, "[") {
> >>>                 i := strings.Index(typ, "]") + 1
> >>>                 name = name + typ[:i]
> >>>                 typ = typ[i:]
> >>>         }
> >>> +       // X *byte -> *X byte
> >>> +       for strings.HasPrefix(typ, "*") {
> >>> +               name = "*" + name
> >>> +               typ = typ[1:]
> >>> +       }
> >>>         // X T -> T X
> >>>         // Handle the special case: 'unsafe.Pointer' is 'void *'
> >>>         if typ == "unsafe.Pointer" {
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> ---You received this message because you are subscribed to the Google
> >>> Groups "golang-dev" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send an
> >>> email to mailto:golang-dev+unsubscribe@googlegroups.com.
> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>
> >>>
> >>
> >> --
> >>
> >> ---
> >> You received this message because you are subscribed to the Google Groups
> >> "golang-dev" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to mailto:golang-dev+unsubscribe@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> 
> 
> 
> -- 
> ~Kevin

[bradfitz, 2013-07-23 16:35:50]

R=iant

[iant, 2013-07-24 18:54:38]

Can you verify that the generated files like pkg/runtime/defs_linux_amd64.h are
not changed by this?

https://codereview.appspot.com/11377043/diff/18001/misc/cgo/testcdefs/issue11...
File misc/cgo/testcdefs/issue11377043.c (right):

https://codereview.appspot.com/11377043/diff/18001/misc/cgo/testcdefs/issue11...
misc/cgo/testcdefs/issue11377043.c:1: // Copyright 2012 The Go Authors.  All
rights reserved.
s/2012/2013/

https://codereview.appspot.com/11377043/diff/18001/misc/cgo/testcdefs/issue11...
misc/cgo/testcdefs/issue11377043.c:6: #include "issue11377043.h"
The issueNNNN naming refers to issue numbers at
http://code.google.com/p/go/issues.  It doesn't make to use the same naming to
revert to a CL number at http://codereview.appspot.com.

[klueska, 2013-07-24 21:04:11]

I have verified this for linux-386 and linux-amd64.  Running the
following script from $GOROOT/src returns nothing.

cd pkg/runtime
diff <(GOARCH=amd64 ../../../bin/go tool cgo -cdefs defs_linux.go
defs1_linux.go) defs_linux_amd64.h
diff <(GOARCH=386 ../../../bin/go tool cgo -cdefs defs2_linux.go)
defs_linux_386.h
cd - > /dev/null

Kevin

On Wed, Jul 24, 2013 at 11:54 AM,  <iant@golang.org> wrote:
> Can you verify that the generated files like
> pkg/runtime/defs_linux_amd64.h are not changed by this?
>
>
>
https://codereview.appspot.com/11377043/diff/18001/misc/cgo/testcdefs/issue11...
> File misc/cgo/testcdefs/issue11377043.c (right):
>
>
https://codereview.appspot.com/11377043/diff/18001/misc/cgo/testcdefs/issue11...
> misc/cgo/testcdefs/issue11377043.c:1: // Copyright 2012 The Go Authors.
> All rights reserved.
> s/2012/2013/
>
>
https://codereview.appspot.com/11377043/diff/18001/misc/cgo/testcdefs/issue11...
> misc/cgo/testcdefs/issue11377043.c:6: #include "issue11377043.h"
> The issueNNNN naming refers to issue numbers at
> http://code.google.com/p/go/issues.  It doesn't make to use the same
> naming to revert to a CL number at http://codereview.appspot.com.
>
> https://codereview.appspot.com/11377043/



--
~Kevin

[iant, 2013-07-24 22:37:03]

Looks good.  Have you signed at the CLA as described near the end of
http://golang.org/doc/contribute.html ?

[klueska, 2013-07-24 23:09:59]

I just signed and submitted the individual contributors form.


On Wed, Jul 24, 2013 at 3:37 PM,  <iant@golang.org> wrote:
> Looks good.  Have you signed at the CLA as described near the end of
> http://golang.org/doc/contribute.html ?
>
>
> https://codereview.appspot.com/11377043/



-- 
~Kevin

[iant, 2013-07-25 00:27:12]

LGTM

[iant, 2013-07-25 00:27:48]

*** Submitted as https://code.google.com/p/go/source/detail?r=c8e02f321281 ***

cmd/cgo: Fix issue with cgo cdefs

The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
properly translating the Go array type to a C array type when an
asterisk follows the [] in the array type declaration (it is perfectly
legal to put the asterisk on either side of the [] in go syntax,
depending on how you set up your pointers).

That said, the cdefs tool is only designed to translate from Go types
generated using the cgo *godefs* tool -- where the godefs tool is
designed to translate gcc-style C types into Go types. In essence, the
cdefs tool translates from gcc-style C types to Go types (via the godefs
tool), then back to kenc-style C types. Because of this, cdefs does not
need to know how to translate arbitraty Go types into C, just the ones
produced by godefs.

The problem is that during this translation process, the logic is
slightly wrong when going from (e.g.):

char *array[10];
to:
array [10]*int8;
back to:
int8 *array[10];

In the current implementation of cdecl(), the translation from the Go
type declaration back to the kenc-style declaration looks for Go
types of the form:

name *[]type;
rather than the actual generated Go type declaration of:
name []*type;

Both are valid Go syntax, with slightly different semantics, but the
latter is the only one that can ever be generated by the godefs tools.
(The semantics of the former are not directly expressible in a
single C statement -- you would have to have to first typedef the array
type, then declare a pointer to that typedef'd type in a separate
statement).

This commit changes the logic of cdecl() to look properly for, and
translate, Go type declarations of the form:
name []*type;

Additionally, the original implementation only allowed for a single
asterisk and a single sized aray (i.e. only a single level of pointer
indirection, and only one set of []) on the type, whereas the patched
version allows for an arbitrary number of both.

Tests are included in misc/cgo/testcdefs and the all.bash script has been
updated to account for these.

R=golang-dev, bradfitz, dave, iant
CC=golang-dev
https://codereview.appspot.com/11377043

Committer: Ian Lance Taylor <iant@golang.org>