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

[Shiva Chen via cfe-dev]

Hi Hubert and Liu Hao,

Thanks for your guidance and make the question more clear.
When the value is not stored back into the bit-field member, it will
involve integer promotion.
The integer promotion rule for bit-filed defined in C99 6.3.1.1/2.
However, the integer promotion rule for other implementation-defined
bit-field type
(width wider than int such as unsigned long long bit field type) was not clear.
So the question become should the implementation-defined bit-field
type do the promotion.
GCC choose not to and Clang will.
There is some discussion in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_315.htm
As Hubert said, the answer will determine until the C standard mention
the rule for implementation-defined bit-field type.

2017-04-21 2:47 GMT+08:00 Hubert Tong <hubert.reinterpretcast at gmail.com>:
> 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
>>
>