3

I'm currently porting some code from another platform and bools on the new platform are 1-byte sized. This is breaking our loading code as the values are stored as 32-bit values. Furthermore, speed is a critical issue on our platform and we would like to use 32-bit bools as the processor runs at 32-bits natively and requires extra operations to compare non 32-bit bools.

Is there a way to force gcc to use 32-bit bools instead of 8-bit bools?

Grant Peters
  • 7,691
  • 3
  • 45
  • 57
  • Sadly, I only know of the -mone-byte-bool switch on Apple's GCC, but it does the opposite of what you want. – Julio Gorgé Dec 15 '10 at 02:49
  • I suppose fixing your loading code is out of the question? (it really shouldn't make assumptions about the size of built-in types like `int` or `bool`) – jalf Dec 15 '10 at 08:37
  • Turns out that the loading code already handle the difference in sizes correctly. The problem came from another part of the loading code that assumed an enum would be 4 bytes in size. That was solved by simply having a 'FORCE_DWORD' value in there. – Grant Peters Dec 23 '10 at 14:28

5 Answers5

6

Add #define BOOL_TYPE_SIZE 4 to gcc/config/i386/i386.h and recompile gcc ;)

eater
  • 2,697
  • 1
  • 21
  • 24
4

The size of bool is implementation defined (5.3.3), and gcc doesn't appear to provide an option to configure this at run-time.

Hopefully your implementation-defined code is isolated. If so, change your bools to ints, or change your loading code to deal with sizeof() == 1 instead of 4.

(Or, for the crazy, alter gcc to treat bool as a 4-byte type.)

Edit: Paul Tomblin's suggestion of using #define may not be legal [see here], but it does work under gcc 4.1.2, at least. [Link] However, if you don't hit every usage of bool the size mismatch will almost certainly bite you.

Community
  • 1
  • 1
Bill
  • 14,257
  • 4
  • 43
  • 55
  • The way I'm reading the answer to the linked questions is that it's illegal to do `#define bool int` before including a standard header, but it's ok to do it after. You can't expect to change the length of bools in code you're not compiling, like external (and standard) libraries. – Paul Tomblin Dec 15 '10 at 03:19
  • @Paul: That, and you'll get compilation errors if they specialized templates on both bool and int. (Such as `iostream`.) The real challenge is that if `bool` is so widely spread in their codebase that they can't just `s/bool/int/g`, then failing to do the `#define` in every location that uses `bool` could be a real issue. – Bill Dec 15 '10 at 05:46
2
#define bool int
Paul Tomblin
  • 179,021
  • 58
  • 319
  • 408
  • 6
    @wilx, if the loading code is written so that the size of the bool is assumed in too many places to just fix it, then the code is already stupid and broken. – Paul Tomblin Dec 15 '10 at 11:38
1

You could create your own class that uses int32_t internally but behaves like a bool. It does mean you'd have to rename the fields you specifically want to use that type, which is more work but affords better control and isolation, and you can still use real bools elsewhere. I'd personally prefer that to any #define hackery, which might bite somewhere unexpected. I'd also caution against assuming a 32-bit int will be usefully faster than a single byte... other factors like pipelining, memory latencies, cache sizes etc. could render the difference insignificant or even make 32-bit ints slower, so you might want to benchmark it in your system with representatitive data handling.

Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
  • This is actually the option I came up with shortly after posting this. Wasn't ideal, but was better than a typedef/#define as I needed the difference between the types to be recognizable by the compiler. – Grant Peters Dec 23 '10 at 14:26
1

You need to separate your internal data structures from the storage/loading code. Simply store the bools in your internal data structures in your platform's native bool type and do the appropriate conversion from/to the storage's one byte bools when reading/writing the data.

wilx
  • 17,697
  • 6
  • 59
  • 114