cmd/cgo: map sized integer types to C equivalents #29878
Comments
|
Fine with me. |
ianlancetaylor
added
help wanted
NeedsFix
The exact-width integer types are required to use two’s complement representation and may not have padding bits, cf. §7.20.1.1/1 in the C11 standard or https://en.cppreference.com/w/c/types/integer. This ensures that they have the same domain and representation as the corresponding Go types. Fixes golang#29878
|
Change https://golang.org/cl/159258 mentions this issue: |
|
I'm looking into this, is updating the (*typeConv).Type method in src/cmd/cgo/gcc.go sufficient to implement the equivalence? A quick experiment seems to show that it is. edit: ninja'd. (And the answer turns out to be no.) |
The exact-width integer types are required to use two’s complement representation and may not have padding bits, cf. §7.20.1.1/1 in the C11 standard or https://en.cppreference.com/w/c/types/integer. This ensures that they have the same domain and representation as the corresponding Go types. Fixes golang#29878
The exact-width integer types are required to use two’s complement representation and may not have padding bits, cf. §7.20.1.1/1 in the C11 standard or https://en.cppreference.com/w/c/types/integer. This ensures that they have the same domain and representation as the corresponding Go types. Fixes golang#29878
The exact-width integer types are required to use two’s complement representation and may not have padding bits, cf. §7.20.1.1/1 in the C11 standard or https://en.cppreference.com/w/c/types/integer. This ensures that they have the same domain and representation as the corresponding Go types. Fixes golang#29878
The exact-width integer types are required to use two’s complement representation and may not have padding bits, cf. §7.20.1.1/1 in the C11 standard or https://en.cppreference.com/w/c/types/integer. This ensures that they have the same domain and representation as the corresponding Go types. Fixes golang#29878
|
Change https://golang.org/cl/168337 mentions this issue: |
This works around the NetBSD <stdint.h> which defines the type using "#define" rather than typedef. Fixes #30918 Updates #29878 Change-Id: I8998eba52139366ae46762bdad5fcae85f9b4027 Reviewed-on: https://go-review.googlesource.com/c/go/+/168337 Reviewed-by: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
|
This seemed like a reasonable idea, but it breaks existing code (see #31093) and I don't see any way to fix that without losing good error reporting. So I'm going to roll back the two changes and leave this issue closed. Sorry. Perhaps this would have been a good approach if we had started that way, but we didn't. |
|
Change https://golang.org/cl/180357 mentions this issue: |
…ypes" Roll back CL 159258 and CL 168337. Those changes broke existing code. I can't see any way to keep existing code working while also producing good error messages for types like C.ulong (such as the ones already tested for in misc/cgo/errors). This is not an exact roll back because parts of the code have changed since those CLs. Updates #29878 Fixes #31093 Change-Id: I56fe76c167ff0ab381ed273b9ca4b952402e1434 Reviewed-on: https://go-review.googlesource.com/c/go/+/180357 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Could you elaborate? It seems like we could define (See also #13467.) |
|
I tried exactly that--defining them as type aliases--and the effect was that the misc/cgo/error err2.go test failed. It failed because expressions like |
|
Can this issue be reopened now that the PR has been reverted? |
|
Above I commented that I was going to leave the issue closed, because I don't think there is a way to do this that doesn't break existing code. Do you see a way? |
|
It seems to me that the way to do it would be a two-step process:
To my knowledge, no one is working on part (1), but that issue is still open. If/when it is addressed, then this issue could likely also be addressed. |
Ah sorry, I had overlooked that statement. I don't really see a good way either. However, if #29878 (comment) is true, then this might be an option. |
|
OK, reopening. |
gopherbot
added
the
compiler/runtime
(Removing the template since this is an enhancement proposal)
The type mappings at https://golang.org/cmd/cgo/#hdr-Go_references_to_C don't state which Go types the sized C integer types
int8_tetc. are mapped to. In C, these types have the same requirements as the corresponding Go types: they are not allowed to have padding bits and have to use two's complement representation, see https://en.cppreference.com/w/c/types/integer. Therefore, these types are guaranteed to have the same domain and representation as the corresponding Go types. So I propose to always represent these types with each other and formally document that fact. It would reduce the need for casts and would make it more obvious that there's no chance of data loss.The text was updated successfully, but these errors were encountered: