[cfe-dev] [llvm-dev] Unsigned Bitwise Shift for Bit-field Structure

[Hubert Tong via cfe-dev]

On Thu, Apr 20, 2017 at 10:41 AM, Liu Hao <lh_mouse at 126.com> wrote:

> On 2017/4/20 19:20, Hubert Tong wrote:
>
>> It is hardly clear that the rvalue is of type unsigned long long (and
>> not some special bit-field type).
>> See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1260.htm.
>> I have been unable to find further discussion of the issue after
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1270.pdf.
>>
>
> You are right. Let's assume such an implementation exists, and despite
> that type, the result doesn't change: The (indeterminate) value is merely
> truncated earlier, yielding the same value after it is stored into the
> bit-field member.
>
Where the implementation divergence occurs is when the value is not stored
back into the bit-field member.


>
> I also doubt the existence of such an implementation: 6.7.2.1/4 doesn't
> say bit-field types need exist. Their occurrence also lead to problems:
> Would people benefit from it? What will happen if such an rvalue is passed
> to a function taking variable arguments? What will `sizeof(it+1)` where
> `it` has a bit-field type?
>
I agree that it leads to problems. This is the reason why I had the cast to
unsigned long long in my code example (which does demonstrate the existence
of such an implementation, namely GCC): because, without the cast, the
argument may not match with the conversion specification.

I think answering these questions is a job for WG 14 (the C committee).


>
>
> --
> Best regards,
> LH_Mouse
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170420/da1865ff/attachment.html>