qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-24 13:30:09 -07:00
Code Releases Activity
9847c065f4
go/misc/cgo/testcdefs/main.go

14 lines
257 B
Go
Raw Normal View History

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://golang.org/cl/11377043
2013-07-24 18:27:42 -06:00
// Copyright 2013 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
cmd/cgo: fix handling of array of pointers when using clang Clang does not record the "size" field for pointer types, so we must insert the size ourselves. We were already doing this, but only for the case of pointer types. For an array of pointer types, the setting of the size for the nested pointer type was happening after the computation of the size of the array type, meaning that the array type was always computed as 0 bytes. Delay the size computation. This bug happens on all Clang systems, not just FreeBSD. Our test checked that cgo wrote something, not that it was correct. FreeBSD's default clang rejects array[0] as a C struct field, so it noticed the incorrect sizes. But the sizes were incorrect everywhere. Update testcdefs to check the output has the right semantics. Fixes #6292. R=golang-dev, iant CC=golang-dev https://golang.org/cl/22840043
2013-11-07 13:24:51 -07:00
package main
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://golang.org/cl/11377043
2013-07-24 18:27:42 -06:00
cmd/cgo: fix handling of array of pointers when using clang Clang does not record the "size" field for pointer types, so we must insert the size ourselves. We were already doing this, but only for the case of pointer types. For an array of pointer types, the setting of the size for the nested pointer type was happening after the computation of the size of the array type, meaning that the array type was always computed as 0 bytes. Delay the size computation. This bug happens on all Clang systems, not just FreeBSD. Our test checked that cgo wrote something, not that it was correct. FreeBSD's default clang rejects array[0] as a C struct field, so it noticed the incorrect sizes. But the sizes were incorrect everywhere. Update testcdefs to check the output has the right semantics. Fixes #6292. R=golang-dev, iant CC=golang-dev https://golang.org/cl/22840043
2013-11-07 13:24:51 -07:00
import "os"
func test() int32 // in main.c
func main() {
os.Exit(int(test()))
}
Copy Permalink