From: NRK <nrk@disroot.org>
To: Rich Felker <dalias@libc.org>
Cc: "Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>,
musl@lists.openwall.com, "Mike Cui" <cuicui@gmail.com>
Subject: Re: [musl] Potential bug in __res_msend_rc() wrt to union initialization.
Date: Wed, 20 Mar 2024 17:11:16 +0000 [thread overview]
Message-ID: <kpaq6m4zbcl5gdtahqwafvd55oohb3aumfbqe5wdmjju5znfbj@2qeoli6wcifg> (raw)
In-Reply-To: <20240319213640.GN4163@brightrain.aerifal.cx>
> That's simply not true. There is no difference in the rules as
> specified by the standard.
I don't think your assertion is correct, at least it hasn't been
demonstrated.
> ¶19 says:
>
> "all subobjects that are not initialized explicitly shall be
> initialized implicitly the same as objects that have static
> storage duration."
>
> The term "subobject" does not seem to be defined, so there's some
> ambiguity, but I would read ¶19 as applying the above text about
> static unions to automatic ones.
The term subobject might not be clearly defined but there's a strong
indication that it refers to objects contained within an aggregate, and
NOT members of a union. Consider the following case:
struct { int a; int b; } object = { .a = 5 };
Assuming `a` and `b` are subobjects, `a` will be initialized to 5 and
`b` to 0. Which makes sense and is consistent with all existing
implementation I'm aware of. Now consider the same with a union:
union { int a; int b; } object = { .a = 5 };
If `b` is a subobjects then it should be initialized to zero according
to the rule. But that can't happen since that'd overwrite the value of
`a`. This to me is a convincing case that subobjects do not refer to
union members, as there can be only 1 active at a time.
Now I don't agree with clang's decision to not zero the entire union in
case of `{0}`. It's unnecessarily hostile, brings negligible (if any)
gains and *will* be causing bugs (this is the 2nd one I'm witnessing).
But as it currently stands, it's not a wrong interpretation of the
standard either. If the intention was to have no difference between {0}
and {} it has not been written down clearly.
- NRK
prev parent reply other threads:[~2024-03-20 17:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 19:56 Mike Cui
2024-03-18 21:34 ` Rich Felker
2024-03-18 22:22 ` NRK
2024-03-18 22:39 ` [musl] Potential bug in __res_msend_rc() wrt to union initialisation Thorsten Glaser
2024-03-19 0:01 ` [musl] Potential bug in __res_msend_rc() wrt to union initialization Mike Cui
2024-03-19 13:18 ` Rich Felker
2024-03-19 15:04 ` Mike Cui
2024-03-19 15:42 ` Rich Felker
2024-03-19 15:55 ` Mike Cui
2024-03-19 16:08 ` Rich Felker
2024-03-19 16:39 ` Jₑₙₛ Gustedt
2024-03-19 20:47 ` Thorsten Glaser
2024-03-21 10:58 ` Jₑₙₛ Gustedt
2024-03-21 16:41 ` Thorsten Glaser
2024-03-19 21:04 ` NRK
2024-03-19 21:36 ` Rich Felker
2024-03-20 17:11 ` NRK [this message]
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=kpaq6m4zbcl5gdtahqwafvd55oohb3aumfbqe5wdmjju5znfbj@2qeoli6wcifg \
--to=nrk@disroot.org \
--cc=cuicui@gmail.com \
--cc=dalias@libc.org \
--cc=jens.gustedt@inria.fr \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).