tolerate padding in mbstate_t

[Jonathan Wakely]

On 21/01/20 21:36 -0300, Alexandre Oliva wrote:
>
>Padding in mbstate_t objects may get the memcmp to fail.
>Attempt to avoid the failure with zero initialization.
>
>
>Regstrapped on x86_64-linux-gnu, and also tested on a platform that used
>to fail because of padding in std::mbstate_t.  Ok to install?

Under what conditions does this fail? Only for -std=gnu++98 and not
later standards, I assume?

Because since C++11 state_type() does perform zero-initialization of
the whole object (including padding) even if it has a default
constructor.


>
>for  libstdc++-v3/ChangeLog
>
>	* testsuite/27_io/fpos/mbstate_t/1.cc: Zero-init mbstate_t.
>---
> testsuite/27_io/fpos/mbstate_t/1.cc |   28 ++++++++++++++++++++++------
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
>diff --git libstdc++-v3/testsuite/27_io/fpos/mbstate_t/1.cc libstdc++-v3/testsuite/27_io/fpos/mbstate_t/1.cc
>index f92d68f..559bd8d 100644
>--- libstdc++-v3/testsuite/27_io/fpos/mbstate_t/1.cc
>+++ libstdc++-v3/testsuite/27_io/fpos/mbstate_t/1.cc
>@@ -28,8 +28,24 @@
> void test01()
> {
>   typedef std::mbstate_t state_type;
>-  state_type state01 = state_type();
>-  state_type state02 = state_type();
>+  // Use zero-initialization of the underlying memory so that padding
>+  // bytes, if any, stand a better chance of comparing the same.
>+  // Zero-initialized memory is guaranteed to be a valid initial
>+  // state.  This doesn't quite guarantee that any padding bits won't
>+  // be overwritten when copying from other instances that haven't
>+  // been fully initialized: this data type is compatible with C, so
>+  // it is likely plain old data, but it could have a default ctor
>+  // that initializes only the relevant fields, whereas copy-ctor and
>+  // operator= could be implemented as a full-object memcpy, including
>+  // padding bits, rather than fieldwise copying.  However, since
>+  // we're comparing two values copied from the same state_type
>+  // instance (or was this meant to take one of them from pos02 rather
>+  // than both from pos01?),

I don't think so, that wouldn't work. I think pos02 could just be
removed from the test.