Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign updoc: mention "purego" build tag convention somewhere #23172
Comments
This comment has been minimized.
This comment has been minimized.
The code history of protobuf seems to indicate that this very same concept was discussed but not pursued further. I'd like to push this more since I see this distinction in at least 2 packages I own. |
This comment has been minimized.
This comment has been minimized.
I think standardizing a build tag to indicate whether package unsafe is available makes sense.
I disagree. Currently, build tags are strictly a build-system concept. I'd argue the compiler should remain ignorant of them. cmd/compile already has a |
This comment has been minimized.
This comment has been minimized.
/cc @bradfitz who also ran into this with |
This comment has been minimized.
This comment has been minimized.
@shurcooL, I'm still fine with "safe", as long as it's defined (i.e. "code that doesn't import But does it also mean no assembly? Those are the sorts of things that should be clarified, if this is to be blessed somehow. (our own use, wiki page, etc) |
This comment has been minimized.
This comment has been minimized.
@dsnet Can you clarify if your proposal is about documenting Or is it about documenting the fact that |
This comment has been minimized.
This comment has been minimized.
Would this proposal be codified in the standard library somehow, perhaps by adding a |
This comment has been minimized.
This comment has been minimized.
In a previous life, we had to identify versions of libraries, and rapidly found out that that was too coarse a measure. We eventually attached a label via the linker to each entry point*, and could tell if, for example, a call to memcpy allowed overap or not. ' We also used it in migration work, to identify parts of programs that could not be supported on a different OS or hardware platform. You arguably should consider labelling parts of the unsafe library with supported and unsupported by target OS, language or whatever, not the whole library if only one operation is unavailable. --dave |
This comment has been minimized.
This comment has been minimized.
Would this How would this build tag interact with the standard library, where both are used a lot? Does no What is the @shurcooL it sounds like the latter at minimum, the former ideally. |
This comment has been minimized.
This comment has been minimized.
I propose that "safe" be soft signal that a library should have memory safety (i.e., makes no assumptions about how objects are laid out in memory, the architecture endianess, semantics regarding registers, etc). Thus, the "safe" tag has the following properties:
Thus, |
This comment has been minimized.
This comment has been minimized.
Based on discussion with proposal-review:
|
This comment has been minimized.
This comment has been minimized.
On WebAssembly: The wasm backend that I'm working on uses a linear memory, so |
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
I support I don't have any great suggestions for where to document this, but perhaps the godoc for |
This comment has been minimized.
This comment has been minimized.
I wanted to point out that in colloquial usage, I've seen "pure Go" most commonly refer to packages that don't use cgo (but can use The |
This comment has been minimized.
This comment has been minimized.
OK, |
This is the convention that the Go ecosystem is standardizing on. See golang/go#23172.
The proposal in golang/go#23172 was accepted. The "purego" build tag is intended to be a community agreed upon soft-signal to indicate the forbidden use of unsafe, assembly, or cgo. Since GopherJS doesn't support those, it should always use "purego" versions of Go packages when they're available. This is done by always setting the "purego" build constraint. Fixes #746.
The proposal in golang/go#23172 was accepted. The "purego" build tag is intended to be a community agreed upon soft-signal to indicate the forbidden use of unsafe, assembly, or cgo. A change in the future will remove special-casing the appengine and js tags once the related toolchains support purego (possibly after some bake-in period).
The proposal in golang/go#23172 was accepted. The "purego" build tag is intended to be a community agreed upon soft-signal to indicate the forbidden use of unsafe, assembly, or cgo. A change in the future will remove special-casing the appengine and js tags once the related toolchains support purego (possibly after some bake-in period).
The proposal in golang/go#23172 was accepted. The "purego" build tag is intended to be a community agreed upon soft-signal to indicate the forbidden use of unsafe, assembly, or cgo. Since GopherJS doesn't support those, it should always use "purego" versions of Go packages when they're available. This is done by always setting the "purego" build constraint. Document build tags that are set. Bump GopherJS version to 1.9-2. Setting the "purego" build constraint can change behavior in theory. It's better to have a distinct GopherJS version to attribute it to. Fixes #746.
The proposal in golang/go#23172 was accepted. The "purego" build tag is intended to be a community agreed upon soft-signal to indicate the forbidden use of unsafe, assembly, or cgo. A change in the future will remove special-casing the appengine and js tags once the related toolchains support purego (possibly after some bake-in period).
The proposal in golang/go#23172 was accepted. The "purego" build tag is intended to be a community agreed upon soft-signal to indicate the forbidden use of unsafe, assembly, or cgo. A change in the future will remove special-casing the appengine and js tags once the related toolchains support purego (possibly after some bake-in period).
Unsafe pointer arithmetic is not supported under GopherJS, and currently fails silently. Add the `purego` tag, standardized as part of golang/go#23172, in addition to the `appengine` tag kept for backwards compatibility.
Unsafe pointer arithmetic is not supported under GopherJS, and currently fails silently. Add the `purego` tag, standardized as part of golang/go#23172, in addition to the `appengine` tag kept for backwards compatibility.
This comment has been minimized.
This comment has been minimized.
Change https://golang.org/cl/103239 mentions this issue: |
As the number of Go implementations continues to increase, the number of cases where the
unsafe
package is unlikely to work properly also rises. Currently, there isappengine
,gopherjs
, and possiblywasm
where pointer arithmetic is not allowed.Currently, protobuf and other packages special cases build tags for
appengine
andjs
and may need to add others in the near future. It does not scale very well to blacklist specific known Go implementations where unsafe does not work.My proposal is to document
safe
as a community agreed upon tag meaning thatunsafe
should not be used. It is conceivable that this concept be extended to the compiler rejecting programs that useunsafe
when thesafe
tag is set, but I'm currently more interested as a library owner in knowing whether to avoidunsafe
in my own packages.\cc @zombiezen @dneil @neelance @shurcooL