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

spec: ambiguity in definition of alignment #12947

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

Comments

@mdempsky
Copy link
Member

commented Oct 15, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Oct 16, 2015

@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

This comment has been minimized.

Copy link
Member Author

commented Oct 16, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 16, 2015

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

@gopherbot

This comment has been minimized.

Copy link

commented Oct 16, 2015

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
Projects
None yet
4 participants
You can’t perform that action at this time.