From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 2C98D3858C98; Sat, 23 Dec 2023 16:17:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C98D3858C98
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1703348244;
	bh=2YHT0nuHh/Ig9aRwJ+6Lne0E8NpO5UUpxw2KLjblwbo=;
	h=From:To:Subject:Date:From;
	b=fWIPDe5QPKlsh73F3JbSDGfBksWnfVQCEi5F01RzAipw0PYq8o0ef+CXNriiO60Gm
	 Rn8UMlbQmnzFeRf5VGp0/F0vyc/2eU6k+1+JVjQS0tRh3ua7kMK51WXutWNmBi2JT7
	 ukcvsYllOUw6ZMdTUElbs220p2DVgai+AaR5VBaA=
From: "adobriyan at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/113124] New: g++ should relax designated initialiser rules
 for trivial classes (read: C structures) and C arrays.
Date: Sat, 23 Dec 2023 16:17:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adobriyan at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-113124-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113124

            Bug ID: 113124
           Summary: g++ should relax designated initialiser rules for
                    trivial classes (read: C structures) and C arrays.
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adobriyan at gmail dot com
  Target Milestone: ---

Currently, the rules do not allow reordering member initialisation:

    struct S {
        int a;
        int b;
    };
    S s{.b =3D 1, .a =3D 2}; // error

or skipping array element initialisation:

    int a[2] =3D {[1] =3D 1}; // error

First, clang++ allows it with warnings which can be silenced.

Second, both restrictions are major problem for converting C projects to C++
if C99 initialisers are used often.

I have bootable Linux compiled with g++ and it became obvious that some cha=
nges
are such pain points:
1) implicit casts from void* to T*,
2) "broken" C99 initializers (which Linux uses a lot),
3) pointer arithmetic ("void* + int" and "void* - void*").

(1) and (3) happen _a_lot_ but they aren't a problem, because they aren't a
flag day, casts can be added little by little to any project willing to con=
vert
to C++.

However, (2) is a flag day with g++, suddenly lot of stuff won't compile.
Fixing this requires giving up _nice_ C99 feature which people are used to.
As you all know, reodering struct members doesn't force to change all
initialisers.

But at the moment of doing gcc =3D> g++ flip every single structure becomes
trivial class(?) and restrictions apply.

Linux is _full_ of these misordered initialisations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/blo=
ck/fops.c?h=3Dv6.7-rc6#n838
(the order is .llseek, .read_iter, ...)

Arrays can be even more painful:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri=
vers/char/mem.c?h=3Dv6.7-rc6#n685

Note, that the last element is undef ifdef, so less space is wasted,
so giving this array size requires constexpr variable and duplicating ifdef=
s.

Sometimes it is not obvious which elements are reordeded or missing:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net=
/ethtool/common.c?h=3Dv6.7-rc6#n11

Reordered C99 initialisers create problems with maintaining patchset.
Reapplying on top of new version may create some rejects, which are painful=
 for
a human to fix: members can be added/deleted/reorders in main code and then
patch is reordering some members too, so duplicate initializations can appe=
ar
if done wrong,
or more importantly, some initializers can be lost (which is null function
pointer dereference somewhere). I've started to redo every initialisers from
scratch just to minimise about of breakage, otherwise it is very easy to mi=
ss
stuff.=