Size of bool

[Peter Froehlich]

Hi all,

The language specification is careful to state sizes for many types,
but it doesn't for bool. I checked and of course it's 1 byte as it
should be. However, if you're interfacing with C code and want to let
it write into an array of Go bools, it becomes rather important that
the size not change in a later revision of the language. I've love to
see a line in the language specification that makes
unsafe.sizeof(true) == 1 explicit.

Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Dimiter "malkia" Stanev]

Hi Peter, won't uint8 serve better job here? You have to convert, but
you would safely assume that it's 1 byte this way.

Isn't it the same with 'int' - it might be 32bit or 64bit. I know it
does not much make sense for bool to be anything else than a byte -
but I'm not a compiler writer.

On Dec 15, 11:23 am, Peter Froehlich <peter.hans.froehl...@gmail.com>
wrote:

[Qtvali]

On Dec 15, 9:23 pm, Peter Froehlich <peter.hans.froehl...@gmail.com>
wrote:

> Hi all,
>
> The language specification is careful to state sizes for many types,
> but it doesn't for bool. I checked and of course it's 1 byte as it
> should be. However, if you're interfacing with C code and want to let
> it write into an array of Go bools, it becomes rather important that
> the size not change in a later revision of the language. I've love to
> see a line in the language specification that makes
> unsafe.sizeof(true) == 1 explicit.

For speed, booleans are often stored with placeholders in many
languages. I would personally also like to see 1-bit boolean type,
which does some checks for me and keeps several of them in byte.

I think that creating explicit bool8 type would be better idea - as in
int32.

Also, I guess that when there is a strong reason to change boolean
length on some architecture, both Go and OpenAL creators use the same
kind of bool there - be it bool1 or bool64. Java creators probably
switch to bool 512 in advance should that happen ;)

[Peter Froehlich]

On Tue, Dec 15, 2009 at 2:32 PM, Dimiter "malkia" Stanev
<mal...@gmail.com> wrote:
> Hi Peter, won't uint8 serve better job here? You have to convert, but
> you would safely assume that it's 1 byte this way.

Yeah, that's the best alternative if I can't get the rule put into the
language spec. :-D But I'd have to convert from []uint8 to []bool
then. Not a big deal of course, but I though I'd bring this up anyway.

[Peter Froehlich]

On Tue, Dec 15, 2009 at 2:35 PM, Qtvali <qtv...@gmail.com> wrote:
> Also, I guess that when there is a strong reason to change boolean
> length on some architecture, both Go and OpenAL creators use the same
> kind of bool there

/usr/include/AL/al.h:

...
/** 8-bit boolean */
typedef char ALboolean;
...

So as long as "char" is 8 bits in C, that's what OpenAL uses. It's
also why I bring up that Go doesn't say anything about
unsafe.sizeof(true) in the spec. The next thing I'd have to bring up
is whether true is 1 and false is 0 but I thought I'd start with the
size first.

[Tambet]

This override is there only to change the type without breaking apps. Or to look like other types, which are defined like that. Definition itself doesn't say that new versions of OpenAL are certantly with that type - no more than Go's current behavior proves the same about Go.

Tambet

2009/12/15 Peter Froehlich <peter.hans...@gmail.com>

[Russ Cox]

> The language specification is careful to state sizes for many types,
> but it doesn't for bool. I checked and of course it's 1 byte as it
> should be. However, if you're interfacing with C code and want to let
> it write into an array of Go bools, it becomes rather important that
> the size not change in a later revision of the language. I've love to
> see a line in the language specification that makes
> unsafe.sizeof(true) == 1 explicit.

If you want to assume this, fine, but you need to accept
in doing so that it is an unsafe assumption and might not
be true in the future. Similarly, if you assume that
sizeof(int) == 4 or that sizeof(Go's int) == sizeof(C's int)
your code might also break in the future.

If you need to make these assumptions for performance
reasons, then document and live with them.

But if you don't need the performance, it would be safer to
write correct code that copies the array from C types
to Go types and back. For example, see
http://golang.org/src/pkg/syscall/syscall_linux.go#L66
which is careful not to assume that C's gid_t and
Go's int are the same size, even though in practice
they often are.

Russ

[Bob Cunningham]

On 12/15/2009 11:43 AM, Peter Froehlich wrote:
> On Tue, Dec 15, 2009 at 2:32 PM, Dimiter "malkia" Stanev
> <mal...@gmail.com> wrote:
>> Hi Peter, won't uint8 serve better job here? You have to convert, but
>> you would safely assume that it's 1 byte this way.
>
> Yeah, that's the best alternative if I can't get the rule put into the
> language spec. :-D But I'd have to convert from []uint8 to []bool
> then. Not a big deal of course, but I though I'd bring this up anyway.

I'd prefer byte, simply to keep bool away from numeric types.