[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Re: boolean usage

Joel C. Salomon

5/16/2011 5:53:00 PM

On Monday, May 16, 2011 11:09:39 AM UTC-4, Keith Thompson wrote:
> Datesfat Chicks <datesfa...@gmail.com> writes:
> [...]
> > I typically use _Bool_ or _Boolean_ (forget what the right keyword
> > is). Anyway, that does a few neat things in the development tools:
> >
> > a)It causes the linker to manage RAM at the bit level (rather than the
> > byte level). So you can link a bunch of modules together each with
> > _Bool_'s, and variables from different modules are actually often in
> > the same byte. No RAM wasted! The tools pack the bits.
> [...]
>
> Either your tools are generating C code that emulates 1-bit objects
> using either bit fields or bitwise operations, or your C compiler
> is non-conforming. In standard C, if you apply sizeof to an object,
> type, or expression of any type, the result is at least 1 byte,
> which is at least 8 bits. (sizeof can't be applied to bit fields.)

A _Bool object whose address is never taken doesn't *actually* need to take up a full byte of memory; so long as you don't notice it, this is a conforming optimization.

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?
2 Answers

Shao Miller

5/16/2011 6:21:00 PM

0

On 5/16/2011 13:53, Joel C. Salomon wrote:
> On Monday, May 16, 2011 11:09:39 AM UTC-4, Keith Thompson wrote:
>> Datesfat Chicks<datesfa...@gmail.com> writes:
>> [...]
>>> I typically use _Bool_ or _Boolean_ (forget what the right keyword
>>> is). Anyway, that does a few neat things in the development tools:
>>>
>>> a)It causes the linker to manage RAM at the bit level (rather than the
>>> byte level). So you can link a bunch of modules together each with
>>> _Bool_'s, and variables from different modules are actually often in
>>> the same byte. No RAM wasted! The tools pack the bits.
>> [...]
>>
>> Either your tools are generating C code that emulates 1-bit objects
>> using either bit fields or bitwise operations, or your C compiler
>> is non-conforming. In standard C, if you apply sizeof to an object,
>> type, or expression of any type, the result is at least 1 byte,
>> which is at least 8 bits. (sizeof can't be applied to bit fields.)
>
> A _Bool object whose address is never taken doesn't *actually* need to take up a full byte of memory; so long as you don't notice it, this is a conforming optimization.
>
> 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?

Is there a typographical error on the second line? I think 'bits' would
turn into a 'bool *' pointing at the first element, which would mean
'bits' wouldn't be == NULL, which would make 'bp' true, wouldn't it?

Seebs

5/16/2011 7:10:00 PM

0

On 2011-05-16, Joel C. Salomon <joelcsalomon@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.)

So I think it's prohibited, but if you happen never to do anything which
would detect this, and the compiler can prove that you never do such a thing,
I assume it'd be allowed.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.