On Jan 21, 2020, Jonathan Wakely <jwak...@redhat.com> wrote:
> 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.
Err, IIUC it does so only for defaulted ctors; a user-supplied default
ctor (as in the target system) may leave padding bits uninitialized.
Indeed, compiling the following snippet without optimization, with or
without -DCTOR, on x86_64, uses movw to initialize bar and the rest of
the word remains uninitialized with -DCTOR, even with -std=c++17, as we
do without -DCTOR with -std=c++98, whereas without -DCTOR and
-std=c++1[17] we use movq.
struct t {
long foo;
short bar;
#if CTOR
t() : foo(0), bar(0) {}
#endif
};
t f() {
t v = t();
return v;
}
When optimiizing, we end up using movq in all cases, but that's probably
because of SRA.
> I don't think so, that wouldn't work. I think pos02 could just be
> removed from the test.
Will do.
--
Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo
Free Software Evangelist Stallman was right, but he's left :(
GNU Toolchain Engineer FSMatrix: It was he who freed the first of us
FSF & FSFLA board member The Savior shall return (true);
