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]

Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful

From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
To: mh at novell dot com
Cc: dnovillo at google dot com, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, rguenther at suse dot de
Date: Wed, 05 Mar 2008 09:28:55 EST
Subject: Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful
References: <Pine.LNX.4.64.0803051312050.4133@zhemvz.fhfr.qr> <47CE9668.8030707@google.com> <20080305141940.GH5847@saturn.hollstein.homelinux.org>

> > >+ 	      if (INTEGRAL_TYPE_P (TREE_TYPE (t))
> > >+ 		  && (TYPE_PRECISION (TREE_TYPE (t))
> > >+ 		      != TREE_INT_CST_LOW (TREE_OPERAND (t, 1))))
> > >+ 		{
> > >+ 		  error ("integral result type precision does not match "
> > >+ 			 "field size of BIT_FIELD_REF");
> > >+ 		  return t;
> > >+ 		}
> > >+ 	      if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
> > 
> > 'else if' here?
> 
> In theory, yes, but, why? 

It's easier to read at-a-glance.  A reader can tell quickly that the 
intent is that only one of the options be taken.  It's easier to spot
the "else" than the "return" in the body.

References:
- [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful
  - From: Richard Guenther
- Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful
  - From: Diego Novillo
- Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful
  - From: Manfred Hollstein

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]