Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: unsafe: Sizeof isn't unsafe and could be elsewhere #5602

Closed
robpike opened this issue May 31, 2013 · 9 comments
Closed

proposal: unsafe: Sizeof isn't unsafe and could be elsewhere #5602

robpike opened this issue May 31, 2013 · 9 comments
Labels
FrozenDueToAge LanguageChange NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. v2 A language change or incompatible library change
Milestone

Comments

@robpike
Copy link
Contributor

robpike commented May 31, 2013

For Go 2, find a better package for unsafe.Sizeof and maybe unsafe.Alignof and
unsafe.Offsetof.
@robpike
Copy link
Contributor Author

robpike commented May 31, 2013

Comment 1:

Labels changed: added languagechange.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 2:

Labels changed: added repo-main.

@rsc
Copy link
Contributor

rsc commented Mar 3, 2014

Comment 3:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

@robpike robpike added accepted v2 A language change or incompatible library change LanguageChange labels Mar 3, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc changed the title unsafe: unsafe.Sizeof isn't really unsafe and could be elsewhere unsafe: Sizeof isn't unsafe and could be elsewhere Jun 17, 2017
@rsc rsc changed the title unsafe: Sizeof isn't unsafe and could be elsewhere proposal: unsafe: Sizeof isn't unsafe and could be elsewhere Jun 17, 2017
@ianlancetaylor
Copy link
Contributor

A program that uses unsafe.Sizeof and friends is sacrificing a certain degree of platform independence. That seems to be the main argument for keeping them in unsafe. (The other thing that makes programs platform dependent is the size of int; that would be addressed if we adopted #19623).

If we do move these functions out of unsafe, they could become predeclared identifiers like len, or we could invent another package known to the compiler. builtin? reflect?

@bradfitz
Copy link
Contributor

It's already in reflect. It's just not as efficient. I suppose the compiler could recognize at least certain (simple) uses of reflect.Type.Size, though.

@bradfitz
Copy link
Contributor

@mdempsky
Copy link
Member

A simpler solution would probably be for safe mode to only deny access to type unsafe.Pointer, not the entire package unsafe.

@robpike
Copy link
Contributor Author

robpike commented Nov 30, 2017

People are confused by Sizeof. They think it's like C sizeof (although that might not be how they would describe it themselves). But it's really not, or at least not in a way that's simple to describe. It's hard to define it in a non-operational way. Just look at go doc unsafe.sizeof.

I think a better idea is to make it portable to ask the simple-to-answer questions, perhaps by constants in the reflect or runtime packages: SizeofInt, SizeofBool, etc. We'd leave out SizeofSlice and SizeofString and such because they are confusing.

In other words, handle the safe (that is, simple and non-confusing) case safely, and leave the nastier cases in package unsafe.

@ianlancetaylor ianlancetaylor added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Dec 5, 2017
@ianlancetaylor
Copy link
Contributor

There doesn't seem to be a strong reason to implement this change. We can consider Rob's suggestion above (runtime.SizeofInt, ...) separately.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

6 participants