[Bug c++/95609] New: span<T> could have better layout

[Bug c++/95609] New: span<T> could have better layout

[s_gccbugzilla at nedprod dot com]

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

            Bug ID: 95609
           Summary: span<T> could have better layout
           Product: gcc
           Version: 10.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
span<T> could instead have the layout:

{
  T *p;
  size_t l;
}

... then a span<byte> would be layout-compatible with struct iovec, which would
save libstdc++ having to reimplement span<> with a struct iovec compatible
layout for any future std::file_handle::buffer_type, if that gets standardised.

I put notice of this out onto lib-ext last year requesting this of span<T>
implementations. libc++ heeded my request, MSVC have very kindly undone their
initial implementation to meet the pointer + size layout plus add standard
layout, so they'll be on that too going forth.

In the end, this request is about as unimportant for right now as you can get.
It's purely for saving you, Jonathan, avoidable work later on.

Niall

[Bug c++/95609] span<T> could have better layout

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Niall Douglas from comment #0)
> I would assume that the ABI ship has sailed, as usual

Nope.

[Bug c++/95609] span<T> could have better layout

[s_gccbugzilla at nedprod dot com]

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

--- Comment #2 from Niall Douglas <s_gccbugzilla at nedprod dot com> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Niall Douglas from comment #0)
> > I would assume that the ABI ship has sailed, as usual
> 
> Nope.

Ok, so if you did want to reuse span<byte> as any future
std::file_handle::buffer_type, the following program would compile:

```
#include <span>
#include <type_traits>
#include <sys/uio.h>

using buffer_type = std::span<std::byte>;

static_assert(sizeof(buffer_type) == sizeof(struct iovec));
static_assert(std::is_trivially_copyable_v<buffer_type>);
static_assert(std::is_standard_layout_v<buffer_type>);
static_assert(std::is_layout_compatible_v<buffer_type, struct iovec>);
```

[Bug c++/95609] span<T> could have better layout

[redi at gcc dot gnu.org]

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

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. 
  size_t  iov_len   The size of the memory pointed to by iov_base. 

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

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, Solaris
11, FreeBSD 12 and OpenBSD 6.6, which means we can assume it's true for most of
the widely-used unix-like systems.

[Bug libstdc++/95609] span<T> could have better layout

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:0f7cd5e5735e5536bf7bc8ca2b998f7ce8b4ddee

commit r11-4475-g0f7cd5e5735e5536bf7bc8ca2b998f7ce8b4ddee
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Oct 28 12:07:40 2020 +0000

    libstdc++: Make std::span layout-compatible with struct iovec [PR 95609]

    This change reorders the data members of std::span so that span<byte> is
    layout-compatible with common implementations of struct iovec. This will
    allow span<byte> to be used directly in places that use a struct iovec
    to do scatter-gather I/O.

    It's important to note that POSIX doesn't specify the order of members
    in iovec. Also the equivalent type on Windows has members in the other
    order, and uses type ULONG (which is always 32-bit whereas size_t is
    64-bit for Win64). So this change will only help for certain targets and
    an indirection between std::span and I/O system calls will still be
    needed for the general case.

    libstdc++-v3/ChangeLog:

            PR libstdc++/95609
            * include/std/span (span): Reorder data members to match common
            implementations of struct iovec.
            * testsuite/23_containers/span/layout_compat.cc: New test.

[Bug libstdc++/95609] span<T> could have better layout

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |11.0
         Resolution|---                         |FIXED

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for GCC 11, not appropriate to backport.

[Bug libstdc++/95609] span<T> could have better layout

[s_gccbugzilla at nedprod dot com]

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

--- Comment #6 from Niall Douglas <s_gccbugzilla at nedprod dot com> ---
Cool, thanks. I believe that all three major STLs now implement struct iovec
compatibility with span<const char>. That's a nice win.

[Bug libstdc++/95609] span<T> could have better layout

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Niall Douglas from comment #0)
> I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
> span<T> could instead have the layout:
> 
> {
>   T *p;
>   size_t l;
> }
> 
> ... then a span<byte> would be layout-compatible with struct iovec,

No it won't, because iovec has a void* member, and span<byte> has a byte*
member, which makes them not layout-compatible. Similarly for span<const char>
or any other specialization of span.

[Bug libstdc++/95609] span<T> could have better layout

[s_gccbugzilla at nedprod dot com]

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

--- Comment #8 from Niall Douglas <s_gccbugzilla at nedprod dot com> ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Niall Douglas from comment #0)
> > I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
> > span<T> could instead have the layout:
> > 
> > {
> >   T *p;
> >   size_t l;
> > }
> > 
> > ... then a span<byte> would be layout-compatible with struct iovec,
> 
> No it won't, because iovec has a void* member, and span<byte> has a byte*
> member, which makes them not layout-compatible. Similarly for span<const
> char> or any other specialization of span.

It is indeed a shame that the compiler won't optimise this appropriately
without additional markup on the iovec structure:

https://godbolt.org/z/cTo5xPxjE

I can tell you that in LLFIO we simply reinterpret cast on those platforms
where we know they'll be bit identical because a bunch of static asserts
wouldn't have allowed compilation otherwise.

Niall