mailing list of musl libc
 help / color / mirror / code / Atom feed
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

      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).