Re: typeof and bitfields

[Matt Austern <austern at apple dot com>]

On Jan 18, 2005, at 9:28 AM, Mark Mitchell wrote:

> Gabriel Dos Reis wrote:
> > Mark Mitchell <mark@codesourcery.com> writes:
> > | Gabriel Dos Reis wrote:
> > | > Alexandre Oliva <aoliva@redhat.com> writes:
> > | > | On Jan 14, 2005, Gabriel Dos Reis <gdr@integrable-solutions.net>
> > | > wrote:
> > | > | | > That is an argument for not returning an int.  It is not an
> > | > argument
> > | > | > for issueing error.  Why not return int_with_2bits?
> > | > | | Let's see...
> > | | I'm supportive of Joseph's patch.
> > | | The submitter in PR10333 clearly thought that you should get an
> > | int_with_2bits type.  Matt suggested that you should just get
> > | "int". Ian suggested "char".  I see good arguments for all of the
> > | choices.  So, there are no obvious semantics.  Why define an 
> > extension
> > | that the average user has only a 1/3 chance of understanding?
> > If you take that observation seriously, then you should remove nearly
> > all extensions plus at least half of standard language semantics.
>
> That's a reduction-to-absurdity argument.  The standard language 
> semantics are not up for debate; some people like them, some people 
> don't, but they are what they are.  Some of our extensions are clearly 
> documented, and, as such, can be put into a similar category.
>
> This extension was not clearly documented.  A user with a reasonable 
> interpretation filed a bug report saying that the compiler was 
> misbehaving, when it chose one of the above alternatives.
>
> > | There's only one good reason, and Matt has already given it: 
> > backwards
> > | compatibility.  Fortunately, that compatibility is only with a GNU
> > | extension used in a pretty obscure way, and there is an easy
> > | workaround (don't use typeof; use the type of the bitfield instead)
> > | that will work in most cases.

There's one other good reason, I think: C/C++ consistency.  It seems 
weird for typeof(x.n) to be allowed in C++ and forbidden in C.  Yes, 
there are differences between those two languages, but a casual user 
could be forgiven for thinking that this should be in the common 
subset.  (And I think it would make more sense to enable this in C than 
to ban it in C++; I can expand on that comment if anyone cares.)

> > The advice "don't use typeof" does not make much sense.  Indeed,
> > typeof is mostly used precisely when the type of the operand it not
> > known, e.g. in macros.
>
> I understand the utility of typeof, but lots of people get by without 
> using typeof at all.  I'm not going to believe that removing the 
> ability to apply typeof to a bitfield is going to cause very many 
> problems for very many people.  How many bug reports have we gotten so 
> far?

I certainly admit this isn't a very important intersection of features. 
 As far as I know I'm the only person to have submitted a bug report on 
this, and I only know of one project at Apple that the removal of 
bitfield typeof has hurt.  That project can probably change its source. 
  3.4 has probably had enough use that we would have known by now if 
this was hurting lots of people.

My only real concern, which again I admit is fairly minor, is that 
we've documented typeof as a mechanism for writing a generic swap macro 
in C.  We've now made it impossible to use this generic swap macro for 
bitfields.

			--Matt