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

[Phil King via cfe-dev]

The important thing here is the implementation defined behaviour.

It is quite reasonable for GCC and Clang to have different behaviours. They should both document what behaviour has been implemented as an implementation is required to document how implementation defined behaviour has been implemented.

Basically, don't expect code that relies on implementation defined behaviour tonne portable.

This is one of the reasons why coding standards such as MISRA highlight such things.

Sent from my iPhone

> On 21 Apr 2017, at 08:59, Shiva Chen via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 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
>>> 
>> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev