Date: Sun, 10 Nov 2024 18:04:31 -0500
On Sun, Nov 10, 2024 at 5:55 PM Mykola Garkusha via Std-Discussion <
std-discussion_at_[hidden]> wrote:
>
>>
> On Sun, Nov 10, 2024 at 8:57 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:
>
>>
>>
>> On 10/11/2024 21.45, Mykola Garkusha via Std-Discussion wrote:
>> > Hi all,
>> >
>> > Currently(unlike C), the standard does not guarantee that padding bits
>> may retain specific values even between sequential reads. Let's exclude
>> tail padding re-use for potentially-overlapping sub-objects. as it is a
>> slightly different matter related to OOP in C++ .
>> >
>> > In C, padding bits are guaranteed to say the same unless you modify the
>> value!
>>
>> Yes.
>>
>> > Also looks like Clang and GCC also follow it, particularly to
>> facilitate atomic operations on objects with padding bits.
>> > Clang and GCC even go further by providing intrinsics to clear padding
>> bits (for example *__builtin_clear_padding* in GCC).
>> >
>> > Is there any chance C++ standard would allow this officially to come
>> closer to the behaviour in C?
>>
>> How would you want to inspect those padding bits portably? And why?
>> What's the use-case?
>>
>
> I don't see anything radically different compared to C, hence I hope
> portability would not be an issue. The main benefit of this change would be
> the ability to compare objects using object representation which is much
> faster. Say one could ensure padding bits set to 0 on creation or during
> the lifetime of an object and later compare the object with *memcmp *knowing
> ahead that the object value does not change and even it does one could
> again reset padding bits to 0 to use *memcmp*
>
Unless I've misunderstood, the C23 draft appears to say that as soon as you
*write* to any member of a struct, all padding bits are reset to
unspecified values.
6.2.6.1/6: *When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object representation that
correspond to any padding bytes take unspecified values* [...]
That seems to prevent the use of `memcmp` for comparing the values of
struct objects in most cases.
Or is the C standard only talking about writes of struct type? (Which, as
you probably know, don't exist in C++: an assignment operator, possibly a
trivial one, is always called.)
>
>> Jens
>>
>> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
std-discussion_at_[hidden]> wrote:
>
>>
> On Sun, Nov 10, 2024 at 8:57 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:
>
>>
>>
>> On 10/11/2024 21.45, Mykola Garkusha via Std-Discussion wrote:
>> > Hi all,
>> >
>> > Currently(unlike C), the standard does not guarantee that padding bits
>> may retain specific values even between sequential reads. Let's exclude
>> tail padding re-use for potentially-overlapping sub-objects. as it is a
>> slightly different matter related to OOP in C++ .
>> >
>> > In C, padding bits are guaranteed to say the same unless you modify the
>> value!
>>
>> Yes.
>>
>> > Also looks like Clang and GCC also follow it, particularly to
>> facilitate atomic operations on objects with padding bits.
>> > Clang and GCC even go further by providing intrinsics to clear padding
>> bits (for example *__builtin_clear_padding* in GCC).
>> >
>> > Is there any chance C++ standard would allow this officially to come
>> closer to the behaviour in C?
>>
>> How would you want to inspect those padding bits portably? And why?
>> What's the use-case?
>>
>
> I don't see anything radically different compared to C, hence I hope
> portability would not be an issue. The main benefit of this change would be
> the ability to compare objects using object representation which is much
> faster. Say one could ensure padding bits set to 0 on creation or during
> the lifetime of an object and later compare the object with *memcmp *knowing
> ahead that the object value does not change and even it does one could
> again reset padding bits to 0 to use *memcmp*
>
Unless I've misunderstood, the C23 draft appears to say that as soon as you
*write* to any member of a struct, all padding bits are reset to
unspecified values.
6.2.6.1/6: *When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object representation that
correspond to any padding bytes take unspecified values* [...]
That seems to prevent the use of `memcmp` for comparing the values of
struct objects in most cases.
Or is the C standard only talking about writes of struct type? (Which, as
you probably know, don't exist in C++: an assignment operator, possibly a
trivial one, is always called.)
>
>> Jens
>>
>> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
-- *Brian Bi*
Received on 2024-11-10 23:04:45