This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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.
| 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.
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.
-- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |