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

[Hubert Tong via cfe-dev]

On Fri, Apr 21, 2017 at 6:00 AM, Phil King <phil_king at rocketmail.com> wrote:

> 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.
>
It is compliant, and perhaps reasonable on a case-by-case basis; however,
Clang "tries" to be GCC-compatible. At the level of implementation-defined
(as opposed to unspecified or undefined) behaviour, I would expect that
Clang would follow what GCC does.

In any case, the choice of whether to perform promotion on the bit-field
types with "base type" and width such that the wording indicates that
promotion does not occur is not implementation-defined behaviour.

What is implementation-defined is whether the use of, e.g., "unsigned long
long" as the "base type" of a bit-field is a constraint violation.


>
> 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.
>
It is unclear as to the intent of the committee; however, the wording has:
"All other types are unchanged by the integer promotions."


> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170421/48fb92f5/attachment.html>