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 EF175393C8AE; Thu, 11 Jun 2020 13:37:10 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF175393C8AE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1591882630;
 bh=SBU8LBNJqwH0LjLSBSEyMuBYs0yDViJHJy0iIuIxkkM=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=QBTKxmJnIMk93H68rc5ygWd2dm1cgiWTBQBmf1GBJM49KDmWnQQNU/CFlR8nuADJa
 wXrO020kIT4q4+KkyugdJsfjMp9iP5fDWqSnE5em2wyUAnUs2L+7VJDfaASDWv6I+3
 V5bfs/F0XlSAYqsHoIV7Mz2lftHjlFyvQcD7yMOQ=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/95609] span<T> could have better layout
Date: Thu, 11 Jun 2020 13:37:10 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 10.1.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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_status everconfirmed cf_reconfirmed_on
Message-ID: <bug-95609-4-1lMQu6iiAg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-95609-4@http.gcc.gnu.org/bugzilla/>
References: <bug-95609-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 13:37:11 -0000

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-06-11

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
As discussed on the reflector, that's only going to work on some targets.

Libstdc++ doesn't dictate the layout of struct iovec, and POSIX only
guarantees:

  The <sys/uio.h> header shall define the iovec structure, which shall
  include at least the following members:

  void   *iov_base  Base address of a memory region for input or output.=20
  size_t  iov_len   The size of the memory pointed to by iov_base.=20

POSIX doesn't say what order the members are in, and allows additional memb=
ers.

So while there is some value making span<byte> layout-compatible with linux=
's
iovec, there's no guarantee it will be usable on other POSIX systems, nor
Windows. So a custom buffer type will probably need to be defined eventually
anyway.

Linux's layout is the obvious one though, and is also used by AIX 7.2, Sola=
ris
11, FreeBSD 12 and OpenBSD 6.6, which means we can assume it's true for mos=
t of
the widely-used unix-like systems.=