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

Jump to bottom

spec: ambiguity in definition of alignment #12947

Open
mdempsky opened this issue Oct 15, 2015 · 4 comments
Open

spec: ambiguity in definition of alignment #12947

mdempsky opened this issue Oct 15, 2015 · 4 comments
Labels
Documentation
Milestone
Unplanned

Comments

@mdempsky
Copy link
Member

The spec (September 24, 2015) says:

The following minimal alignment properties are guaranteed:

  1. For a variable x of any type: unsafe.Alignof(x) is at least 1.
  2. For a variable x of struct type: unsafe.Alignof(x) is the largest of all the values unsafe.Alignof(x.f) for each field f of x, but at least 1.
  3. For a variable x of array type: unsafe.Alignof(x) is the same as unsafe.Alignof(x[0]), but at least 1.

While intuitive, this definition doesn't address structs with blank fields (because there's no valid x.f expression to access those fields) or zero-element arrays (because x[0] is an illegal expression, as 0 is a constant that's out of the array's bounds).

It seems like these can be addressed by changing the wording to something like:

  1. The alignment of any type is at least 1.
  2. The alignment of a struct type is at least as large as the alignment of each of its fields.
  3. The alignment of an array type is the same as the alignment of its element type.

(The original definition repeats the "but at least 1" wording each time, but that seems redundant since nothing else indicates that rule 1 is mutually exclusive with rules 2 and 3.)
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Oct 15, 2015
@griesemer
Copy link
Contributor

@mdempsky Some of the wording here is historic - it's not clear that a field x.f is a "variable" hence some of the repetition. Furthermore, while I like your general rephrasing, it's less precise: unsafe.Alignof doesn't work on types, only expressions (including constants):

package main
import "unsafe"
const c = 2.718
func f() int { return 0 }
func main() {
    println(unsafe.Alignof(3+4))
    println(unsafe.Alignof(c))
    println(unsafe.Alignof(f))
    // println(unsafe.Alignof(int)) // doesn't work for types
}

Should be clarified but is not urgent.

@mdempsky
Copy link
Member Author

@griesemer Understood that unsafe.Alignof only operates on expressions rather than types (aside: I wish it supported both), but the spec defines "alignment" to be a property of types:

Computer architectures may require memory addresses to be aligned; that is, for addresses of a variable to be a multiple of a factor, the variable's type's alignment.

Hence why it seems reasonable to me to word alignment guarantees in terms of types too.

@griesemer
Copy link
Contributor

@mdempsky Happy to review a spec clarification if you want to give it a shot.

@gopherbot
Copy link

CL https://golang.org/cl/16004 mentions this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Documentation
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@mdempsky @ianlancetaylor @griesemer @gopherbot