Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #4115 > unrolled thread

Re: boolean usage

Back to article view | Back to comp.lang.c

Contents

  Re: boolean usage "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-05-16 12:50 -0700
    Re: boolean usage Ian Collins <ian-news@hotmail.com> - 2011-05-17 09:08 +1200

#4115 — Re: boolean usage

On Monday, May 16, 2011 3:10:22 PM UTC-4, Seebs wrote:
> On 2011-05-16, Joel C. Salomon <joelcs...@gmail.com> wrote:
> > Digression:  I've been wondering whether it's possible for a
> >compiler for a bit-addressable machine to get away with tightly-packing
> >_Bools and still somehow get away with lying that sizeof(_Bool)==1.
> >The only way I can think to detect this would be something like
> 
> >   bool bits[16] = {0,0,0,0, 0,0,0,0, 1,1,1,1, 1,1,1,1};
> >   bool bp = bits;
> >   char *cp = (char *)bits;
> >   assert((void *)bp == (void *)cp);
> 
> > -- but is that even mandated?
> 
> Hmm.  Here's my thought.  In such a case, consider the two objects
> bits[3] and bits[5].  Obviously, sizeof(bits[3]) can't be less than 1,
> and CHAR_BIT can't be less than 8, so we know for sure that there are
> 8 consecutive bits which are part of bits[3].  Same for bits[5].  But
> their storage spaces, it seems to me, clearly overlap.  (If not, look
> at bits[4], which will overlap one of them.)

I thought I was missing something obvious; thanks.

I guess the way to "properly" permit this optimization is to use "register _Bool" for individual variables, and bit-fields instead of arrays.  (At least post-TC2, see N1356.)

--Joel

[toc] | [next] | [standalone]

#4121

On 05/17/11 07:50 AM, Joel C. Salomon wrote:

Please stop starting new threads!  Drop that awful new google interface, 
it's ruining Usenet.

-- 
Ian Collins

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web