How big is a boolean?
Paul
I'm writing a universal binary which does a lot of reading/writing data
to hard disk. As the data file needs to be windows compatable it is
little endian and so I swap bytes when running on PPC.
But a bool seems to be 4 bytes on my PPC G4 but 1 byte on my Intel iMac,
is this correct? Haven't checked on Win yet...
Thanks,
Paul
Paul Russell
Binary data fiels are generally a bad idea unless the size of the file
is a genuine concern. Much better to use a text-based format, such as
XML, for a whole raft of reasons.
But assuming that you really are stuck with a binary file format for one
reason or another then yes, there are all sorts of issues, the size of a
bool being just one. If possible you should read/write bools as 32-bit
ints - this helps to maintain padding/alignment, is directly compatible
with OS X, and is not too hard to accommodate in Intel-land.
Paul
Jens Ayton
>
> But assuming that you really are stuck with a binary file format for one
> reason or another then yes, there are all sorts of issues, the size of a
> bool being just one. If possible you should read/write bools as 32-bit
> ints - this helps to maintain padding/alignment, is directly compatible
> with OS X, and is not too hard to accommodate in Intel-land.
More generally, when dealing with binary data, try to stick to sized
types like uint32_t. There's a standard set defined in <stdint.h>.
--
\\\\ Jens Ayton, Fratello di Vetinari 36.3636363636364% insane
\\\\\__, Bringing sarcastic one-liners to the common hedgehog since 1999
\\\\\`/
Paul Russell
> Paul Russell:
>
>>But assuming that you really are stuck with a binary file format for one
>>reason or another then yes, there are all sorts of issues, the size of a
>>bool being just one. If possible you should read/write bools as 32-bit
>>ints - this helps to maintain padding/alignment, is directly compatible
>>with OS X, and is not too hard to accommodate in Intel-land.
>
>
> More generally, when dealing with binary data, try to stick to sized
> types like uint32_t. There's a standard set defined in <stdint.h>.
>
>
Yeah, unfortunately there's no bool32_t though, in either stdint.h or
stdbool.h.
Paul
Wayne C. Morris
Paul Russell <prus...@sonic.net> wrote:
So convert it, store in a non-bool variable, and write from that variable
to the file. Reverse the sequence for reading. The most obvious methods
would be to use either a cast or the "?" operator.
Paul
I'll just read/write it as an UInt16 and endian swap when needed.
Paul
Paul Russell
Well yes, obviously, but it's not a very good solution in the general
case, since you have to handle each bool variable explicitly.
My preferred solution is to define my own bool type and use that
throughout the project, but that's not always an option for legacy code.
Paul
Wayne C. Morris
Paul Russell <prus...@sonic.net> wrote:
> Wayne C. Morris wrote:
>
> > In article <4hvufhF...@individual.net>,
> > Paul Russell <prus...@sonic.net> wrote:
> >
> >>Yeah, unfortunately there's no bool32_t though, in either stdint.h or
> >>stdbool.h.
> >
> > So convert it, store in a non-bool variable, and write from that variable
> > to the file. Reverse the sequence for reading. The most obvious methods
> > would be to use either a cast or the "?" operator.
>
> Well yes, obviously, but it's not a very good solution in the general
> case, since you have to handle each bool variable explicitly.
But you have to handle every numeric variable explicitly anyways.
The OP said at the start of this thread that he needs the file to be
Windows compatible, and he also mentioned having both a G4 and an Intel
Mac. So he has to worry about the byte order as well as the size of every
field; otherwise the file won't be portable between G4 and Intel versions
of his app.
I'd recommend writing the file in "network" byte order (big-endian), unless
he needs compatibility with an existing Windoze app that reads & writes its
files in small-endian.
Yes, it's tedious having to convert a bunch of fields to/from whatever byte
order is used in the file, but it's necessary if you want portable data
files. My preferred solution is to write a handful of functions or macros
that copy variables of specific types to/from the buffer, converting as
necessary.
Simon Slavin
<4hu7drF...@individual.net>:
> Paul wrote:
>
> > I'm writing a universal binary which does a lot of reading/writing data
> > to hard disk. As the data file needs to be windows compatable it is
> > little endian and so I swap bytes when running on PPC.
> >
> > But a bool seems to be 4 bytes on my PPC G4 but 1 byte on my Intel
> > iMac, is this correct? Haven't checked on Win yet...
> Binary data fiels are generally a bad idea unless the size of the file
> is a genuine concern. Much better to use a text-based format, such as
> XML, for a whole raft of reasons.
Yep. If data sizes are important, compress the data when you're not using
it, which is exactly how OS X handles .plist files.
There are exceptions, especially if your file contains /only/ boolean
values and you don't need to handle strings or numbers too. But you're
usually better off with text encoding of some sort, and XML is a good way
to do that these days.
> But assuming that you really are stuck with a binary file format for one
> reason or another then yes, there are all sorts of issues, the size of a
> bool being just one. If possible you should read/write bools as 32-bit
> ints - this helps to maintain padding/alignment, is directly compatible
> with OS X, and is not too hard to accommodate in Intel-land.
But it's worse than that ! How about the difference between Win32 and
Win64 ? And did you notice that TRUE is 1s on some architectures and 0s
on others, depending on how the machine code works ? Or are you assuming
that you'll always be using C and keeping to the C standard for true and
false ?
Simon.
--
http://www.hearsay.demon.co.uk
Michael Ash
>
> Yep. If data sizes are important, compress the data when you're not using
> it, which is exactly how OS X handles .plist files.
Actually, this is not the case. Binary plist files aren't just compressed
XML plist files. There's a special binary plist format that they use which
is capable of storing the same type of data as the other formats.
Compressing the verbose format is a great way to go unless you really need
speed at the CPU level, in which case it's often not. But thinking about
speed violates the first and second rules of optimization, so it's
generally better to just make things simple.
--
Michael Ash
Rogue Amoeba Software