On 10/05/2021 19.52, Inbal Levi via Liaison wrote:
>
> Hello all!
> I would love SG22's input on D2152R1 <https://isocpp.org/files/papers/D2152R1.pdf> of the paper: "P2152: Querying the Alignment of an Object [Aligning Alignment]"

4.1

"Issue [4.1.1]: The standard does not allow alignof(exp) (this is a GNU extension)."

Agreed.

"However, there are multiple references to functionality derived from allowing alignof(exp)."

I can't find any in the standard. Please list those "multiple
references" (in the paper).

"As a result, there is inconsistency between different compilers,"

Not surprising with an extension.

" and within the C++ standard."

Please provide specific evidence.

> The paper was originally created to solve a rather small issue: Core#1008 <https://wiki.edg.com/pub/Wg21summer2020/CoreWorkingGroup/cwg_closed.html#1008> but during the process I have stumbled across a wider issue.

In section 4.1, please say what the desired semantics are supposed to be.

alignof(expr) is the same as alignof(decltype(expr)), or what?
(Note that the object designated by "expr" might happen to be aligned
stricter than its type is required to be.)

> _I would most appreciate the groups' feedback, and particularly on the following:_
>
> 1. My preferred direction is to enforce a striker rule then of C (and which is aligned with Clang's behaviour) regarding alignment specification (reasoning is under section 4.2) but I would love feedback on that.

4.2 claims

"The alignment of an object in C is resolved to the strictest amongst its members"

While I believe such a rule might be reasonable to provide explicitly
(at least for standard-layout or trivial types), I fail to find it in
WG14 N2573 6.7.5. Could you please point to a specific paragraph?

"Consider the following C code:"

Code involving "__attribute__" is neither (standard) C nor C++, I believe.

> 2. The paper does not have a "formal" wording (though it has been reviewed by Daveed on it's early stages) so I would love your input, especially with respect to defining the types of which we enforce the alignment (4.2 again).

[basic.align] The yellow addition should be a note at best.
(The alignment is already implementation-defined, what more to say?)

[expr.alignof] talks about alignof(expr), but doesn't say what it
means at all.

[dcl.align] This wording should move to [basic.align], saying that
the alignment requirement of a (trivial? standard-layout?) class
type is the strictest alignment of its non-static data members or so.

[expr.reinterpret.cast]
I don't know what you want to do here. We already guarantee
you get the original pointer value, which is more than restoring
the bit-pattern. The addition of "alignment" is superfluous
at best and possibly misleading.

Jens