summaryrefslogtreecommitdiff
path: root/misc
diff options
context:
space:
mode:
authorMatthew Dempsky <mdempsky@google.com>2014-08-13 11:16:30 -0700
committerMatthew Dempsky <mdempsky@google.com>2014-08-13 11:16:30 -0700
commit7c540df32ecff7fde7d6fc02ac237d48b85aabb6 (patch)
tree361b349236a7054c841cab2469c25286ee9123ac /misc
parentd5440f8446c6e50b9f0b19d048312765ee86ef68 (diff)
downloadgo-7c540df32ecff7fde7d6fc02ac237d48b85aabb6.tar.gz
cmd/cgo, debug/dwarf: fix translation of zero-size arrays
In cgo, now that recursive calls to typeConv.Type() always work, we can more robustly calculate the array sizes based on the size of our element type. Also, in debug/dwarf, the decision to call zeroType is made based on a type's usage within a particular struct, but dwarf.Type values are cached in typeCache, so the modification might affect uses of the type in other structs. Current compilers don't appear to share DWARF type entries for "[]foo" and "[0]foo", but they also don't consistently share type entries in other cases. Arguably modifying the types is an improvement in some cases, but varying translated types according to compiler whims seems like a bad idea. Lastly, also in debug/dwarf, zeroType only needs to rewrite the top-level dimension, and only if the rest of the array size is non-zero. Fixes issue 8428. LGTM=iant R=iant CC=golang-codereviews https://codereview.appspot.com/127980043 Committer: Ian Lance Taylor <iant@golang.org>
Diffstat (limited to 'misc')
-rw-r--r--misc/cgo/test/issue8428.go48
1 files changed, 48 insertions, 0 deletions
diff --git a/misc/cgo/test/issue8428.go b/misc/cgo/test/issue8428.go
new file mode 100644
index 000000000..f5b0ee497
--- /dev/null
+++ b/misc/cgo/test/issue8428.go
@@ -0,0 +1,48 @@
+// Copyright 2014 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.
+
+package cgotest
+
+// Issue 8428. Cgo inconsistently translated zero size arrays.
+
+/*
+struct issue8428one {
+ char b;
+ char rest[];
+};
+
+struct issue8428two {
+ void *p;
+ char b;
+ char rest[0];
+};
+
+struct issue8428three {
+ char w[1][2][3][0];
+ char x[2][3][0][1];
+ char y[3][0][1][2];
+ char z[0][1][2][3];
+};
+*/
+import "C"
+
+import "unsafe"
+
+var _ = C.struct_issue8428one{
+ b: C.char(0),
+ rest: [0]C.char{},
+}
+
+var _ = C.struct_issue8428two{
+ p: unsafe.Pointer(nil),
+ b: C.char(0),
+ rest: [0]C.char{},
+}
+
+var _ = C.struct_issue8428three{
+ w: [1][2][3][0]C.char{},
+ x: [2][3][0][1]C.char{},
+ y: [3][0][1][2]C.char{},
+ z: [0][1][2][3]C.char{},
+}