Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: bit-fields of type unsigned long and unsigned long long Date: Sat, 10 Jul 2021 09:13:53 -0700 Organization: A noiseless patient Spider Lines: 42 Message-ID: <86mtqu87um.fsf@linuxsc.com> References: <86fsx8bh88.fsf@linuxsc.com> <8635t7ayki.fsf@linuxsc.com> <87zgvfukwa.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="e13df7ffef68eec8a0b0a92150d2f271"; logging-data="2695"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+m7c1oyAUrEkunsH34bJKzmlg6EBwr638=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:otHYMMnTGiwG4qugWL0ah8KzJJg= sha1:J2wYdDxOsYLw/EpuSNKrWghKVSE= Xref: csiph.com comp.std.c:6266 Keith Thompson writes: > Tim Rentsch writes: > >> Philipp Klaus Krause writes: >> >>> Am 23.06.21 um 19:53 schrieb Tim Rentsch: >>> >>>> Bit-fields of types signed and unsigned may use widths up to the >>>> widths of intmax_t and uintmax_t, respectively. >>> >>> WG14 usually doesn't like to use the same syntax as C++ but with a >>> different meaning. >>> AFAIK, in C++, you can have an int bit-field wider than int (or whatever >>> else the type is), but the upper bits then are padding bits. >> >> The obvious answer is to ask the C++ committee to change their >> silly rule. And if they don't want to change it, just ignore it; >> the C++ rule is already incompatible with C, now it will just be >> incompatible in a different way. The gap between C and C++ has >> increased to the point where they should be treated as separate >> and independent languages. > > It's no more incompatible than any other C++ feature that doesn't exist > in C. A program that defines a bit field with a length that exceeds the > width of the type is a constraint violation in C, and valid in C++. I don't know what point you're trying to make here. How it works in C++ is different from how it works in C. That the C standard deems it a constraint violation to me seems irrelevant. The important point is that the behaviors in the two cases aren't the same. > On the other hand, I agree that the C++ rule *seems* silly. I wonder > what the rationale is. (The earliest reference to the rule that I found > is in the C++ 1998 standard.) > > It would be nice to avoid *gratuitous* incompatibilities between C and > C++. It would be even nicer in this particular case if C++ changed its silly rule to the rule I suggested for C.