Skip to content

[expr.sizeof] Clarify sizeof(array) #4808

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

[expr.sizeof] Clarify sizeof(array) #4808

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
43fbd77
[expr.sizeof] Move rule about array layout to [intro.object]
jensmaurer Aug 12, 2021
1f2309e
[expr.sizeof] Integrate footnote into containing note
jensmaurer Oct 24, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions source/basic.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3219,6 +3219,8 @@
Otherwise, the circumstances under which the object has zero size
are \impldef{which non-standard-layout objects
containing no data are considered empty}.

\pnum
\indextext{most derived object!bit-field}%
Unless it is a bit-field\iref{class.bit},
an object with nonzero size
Expand All @@ -3228,6 +3230,12 @@
An object of trivially copyable or
standard-layout type\iref{basic.types.general} shall occupy contiguous bytes of
storage.
An object of array type shall not occupy any byte
that is not occupied by any of its subobjects.
\begin{note}
This implies that \tcode{sizeof(T[n])}
has the same value as \tcode{n * sizeof(T)}.
\end{note}

\pnum
\indextext{most derived object!bit-field}%
Expand Down
13 changes: 6 additions & 7 deletions source/expressions.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4784,10 +4784,8 @@
\begin{note}
In particular, the values of \tcode{\keyword{sizeof}(\keyword{bool})}, \tcode{\keyword{sizeof}(\keyword{char16_t})},
\tcode{\keyword{sizeof}(\keyword{char32_t})}, and \tcode{\keyword{sizeof}(\keyword{wchar_t})} are
implementation-defined.
\begin{footnote}
implementation-defined;
\tcode{\keyword{sizeof}(\keyword{bool})} is not required to be \tcode{1}.
\end{footnote}
\end{note}
\begin{note}
See~\ref{intro.memory} for the definition of byte
Expand All @@ -4803,7 +4801,7 @@
of that class including any padding required for placing objects of that
type in an array.
The result of applying \keyword{sizeof} to a
potentially-overlapping subobject is
potentially-overlapping subobject\iref{intro.object} is
the size of the type, not the size of the subobject.
\begin{footnote}
The actual size of a potentially-overlapping subobject
Expand All @@ -4812,9 +4810,10 @@
and less strict padding requirements on potentially-overlapping subobjects.
\end{footnote}
\indextext{array!\idxcode{sizeof}}%
When applied to an array, the result is the total number of bytes in the
array. This implies that the size of an array of $n$ elements is
$n$ times the size of an element.
\begin{note}
When applied to an array of $n$ elements,
the result is $n$ times the size of an element.
Copy link
Member

@zygoloid zygoloid Sep 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I know this is my wording suggestion, but reading it back in context: We start this paragraph by describing a special case for reference types that doesn't follow the general rule in p1 (and can't because there are no objects of reference type). Following that up with this might be taken as suggesting that this case is also overriding the general rule. Maybe we could move this rule into p1 so it doesn't seem to parallel the reference case?

More drastic suggestion: I wonder if perhaps this wording belongs in [intro.object] instead. Perhaps in paragraph 8 where we talk about objects occupying storage? We could split the second half of p8 into two:

  1. [...] Otherwise, the circumstances under which the object has zero size are implementation-defined.

8+. Unless it is a bit-field (11.4.10), an object with nonzero size shall occupy one or more bytes of storage, including every byte that is occupied in full or in part by any of its subobjects. An object of trivially copyable or standard-layout type (6.8) shall occupy contiguous bytes of storage. An object of array type shall not occupy any byte that is not occupied by any of its subobjects.[Footnote: This implies that sizeof(T[n]) == n * sizeof(T).]

Copy link
Member Author

@jensmaurer jensmaurer Oct 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implemented.

Copy link
Contributor

@tkoeppe tkoeppe Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the wording. Do we all agree that this is editorial?

Copy link
Member Author

@jensmaurer jensmaurer Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's editorial; this is what the standard always said. If you're uncomfortable, let's punt this to "editorial with CWG oversight".

@zygoloid, your input solicited.

Copy link
Member

@zygoloid zygoloid Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do we think the rule for classes is? Is it:

  • an object of class type occupies its tail padding, therefore an object of array type does too
  • an object of class type doesn't occupy its tail padding but as a special case we increase the value produced by sizeof as described above

The first option seems to disallow tail padding reuse (by the "occupy disjoint bytes of storage" rule). The second option seems to mean that sizeof(T[n]) != n * sizeof(T).

I think the conclusion is probably that sizeof(T) can be larger than the number of bytes occupied by T, and this happens precisely when T has tail padding. :(

Copy link
Contributor

@frederick-vs-ja frederick-vs-ja Feb 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the current wording doesn't allow an array element subobject to be potentially-overlapping (but it seems that the array itself is unintendedly allowed, which is meaningless)(CWG2527), and thus it exactly occupies all sizeof(T) bytes according to [expr.sizeof]/1.

IMO nothing is unclear in this PR, but I'm a bit confused that "number of bytes occupied by a non-potentially-overlapping object" is mentioned in [expr.sizeof] only, not in [intro.object].

Copy link
Contributor

@tkoeppe tkoeppe Mar 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jensmaurer Thoughts?

Copy link
Member Author

@jensmaurer jensmaurer Mar 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need a consistent model here, and fixing this is likely CWG material.

\end{note}

\pnum
The lvalue-to-rvalue\iref{conv.lval},
Expand Down