From: Joseph Myers <joseph@codesourcery.com>
To: Kees Cook <keescook@chromium.org>
Cc: Alejandro Colomar <alx.manpages@gmail.com>, GCC <gcc@gcc.gnu.org>,
Alejandro Colomar <alx@nginx.com>,
Andrew Clayton <a.clayton@nginx.com>,
Andrew Clayton <andrew@digital-domain.net>,
<linux-hardening@vger.kernel.org>
Subject: Re: [wish] Flexible array members in unions
Date: Thu, 11 May 2023 22:52:25 +0000 [thread overview]
Message-ID: <a9f2739c-7582-853e-ea94-e13f5ea4698@codesourcery.com> (raw)
In-Reply-To: <202305111514.576EB7F@keescook>
On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> Okay, understood. If this is a C-only thing, we can ignore the C++
> impact.
We're a lot more careful lately in WG14 about checking for C++
compatibility issues and expecting approval from the liaison group for
anything with possible compatibility concerns for syntax in the common
subset of C and C++. So, no, we can't ignore the C++ impact for adding
empty types; it would need careful consideration in the liaison group.
> What depends on the "different objects have different addresses"
> principle? And why do unions not break this -- they could point to the
> same locations within the object? And don't flexible arrays already need
> special handling in this regard?
"including a pointer to an object and a subobject at its beginning" and
"one is a pointer to one past the end of one array object and the other is
a pointer to the start of a different array object that happens to
immediately follow the first array object in the address space" are both
cases included in the semantics for comparison operators. If you allow
zero-size objects you get more special cases there (and quite possibly
affect optimizations based on points-to analysis that can determine
pointers are based on different objects, if an object is not known at
compile time to have nonzero size).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2023-05-11 22:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ac2550e0-2f5c-3680-08e6-0c224d043036@gmail.com>
[not found] ` <44940599-7b43-99f6-5b09-4f050d645c7b@gmail.com>
2023-05-11 19:07 ` [wish] Flexible array members in unions Kees Cook
2023-05-11 20:53 ` Joseph Myers
2023-05-11 21:13 ` Kees Cook
2023-05-11 21:43 ` Joseph Myers
2023-05-11 22:16 ` Kees Cook
2023-05-11 22:52 ` Joseph Myers [this message]
2023-05-12 0:25 ` Alejandro Colomar
2023-05-12 6:16 ` Richard Biener
2023-05-15 19:58 ` Qing Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9f2739c-7582-853e-ea94-e13f5ea4698@codesourcery.com \
--to=joseph@codesourcery.com \
--cc=a.clayton@nginx.com \
--cc=alx.manpages@gmail.com \
--cc=alx@nginx.com \
--cc=andrew@digital-domain.net \
--cc=gcc@gcc.gnu.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.