Boolean types

Posted Apr 26, 2014 15:03 UTC (Sat) by nix (subscriber, #2304)
In reply to: Boolean types by khim
Parent article: Porting the Go compiler to Go

This is a standards-version difference.

C99, which was explicitly mentioned in the parent comment, has none of that language (nor does it have a _Bool type, only bool out of <stdbool.h>, basically an alias for int).

Boolean types

Posted Apr 26, 2014 16:25 UTC (Sat) by khim (subscriber, #9252) [Link] (9 responses)

This is a standards-version difference.
C99, which was explicitly mentioned in the parent comment, has none of that language.

If you find yourself in a hole, stop digging. Please.

C99 (otherwise known as ISO/IEC 9899:1999) most definitely have this language. That's what I've cited. It's on page 43, to be exact. C89, yes that one does not have it, but it's ancient history by now.

Perhaps you think it's some new invention of C11? Nope, not even close. C11 does change the text slightly, but it's just a side-note NaNs do not compare equal to 0 and thus convert to 1. _Bool, stdbool.h, true and false are all defined quite explicitly by C99 standard. And bool is specified (on page 252) is define for a macro that expands to _Bool. Not to int. Not to short or char, but only and exclusively to bool.

As I've said: if you use non-C99-compilant compiler like MSVC then you deserve all the pain you are getting (and yes, such compilers sometimes provide stdbool.h which maps bool to int), but all C99-compilant compilers must provide _Bool type with properties outlined above.

Boolean types

Posted Apr 26, 2014 17:02 UTC (Sat) by HelloWorld (guest, #56129) [Link] (7 responses)

Well, actually the way C99 defines “Booleans” makes them almost completely useless in my opinion.

Boolean types

Posted Apr 28, 2014 7:44 UTC (Mon) by brouhaha (subscriber, #1698) [Link] (6 responses)

Well, actually the way C99 defines “Booleans” makes them almost completely useless in my opinion.

I do a lot of C99 programming, and use stdbool all the time, and it certainly doesn't seem "almost completely useless" to me. But I suppose YMMV.

Boolean types

Posted Apr 28, 2014 10:05 UTC (Mon) by HelloWorld (guest, #56129) [Link] (5 responses)

Well tell me, what *is* the advantage? The only thing people here have mentioned in the past is that a _Bool is guaranteed to contain no value other than 0 or 1. I don't see how that is useful.

Boolean types

Posted Apr 28, 2014 11:10 UTC (Mon) by epa (subscriber, #39769) [Link] (4 responses)

That is highly useful. If I write a function that takes an int, I have to think about and document what it does with each possible integer value. Or else add an explicit precondition that only 0 and 1 are acceptable, in which case it is the caller's responsibility to make sure that only those values can be passed. With _Bool the compiler checks all this for me and I can get on with thinking about the problem I'm trying to solve.

Boolean types

Posted Apr 28, 2014 12:30 UTC (Mon) by mchapman (subscriber, #66589) [Link]

> If I write a function that takes an int, I have to think about and document what it does with each possible integer value. Or else add an explicit precondition that only 0 and 1 are acceptable

Wouldn't it be simpler just documenting the behaviour for a "logically false" value (i.e. 0) and for a "logically true" value (i.e. everything else)?

I can't say I've ever felt the fact that boolean-like ints can take a range of values to be a problem. In practice you usually end up just using them in an if or while condition anyway.

Boolean types

Posted Apr 28, 2014 13:04 UTC (Mon) by HelloWorld (guest, #56129) [Link] (2 responses)

> If I write a function that takes an int, I have to think about and document what it does with each possible integer value.
No, you only have two think about two cases: zero and non-zero, it's completely isomorphic. And the _Bool type is utterly half-assed as it's not strongly typed and the relational operators still evaluate to int instead of _Bool and there are no proper literals: true == 2 is false... err, I mean 0.

_Bool doesn't buy you anything relevant over typedef enum { false, true } bool;, and what's worse, it blocks any kind of true progress, because as soon as anybody wants to add *proper* booleans to the language, everybody else will point to _Bool. What the C committee has done here is just thoroughly idiotic.

Boolean types

Posted Apr 28, 2014 16:03 UTC (Mon) by epa (subscriber, #39769) [Link] (1 responses)

Right, in my program logic I have two cases, but if I am writing code that takes an int then the type signature (or function contract) does nothing to convey to me, the compiler, or other programmers that only two values are expected.

I do agree that the _Bool as defined in C99 is half-assed. It joins the signed/unsigned rules and integer overflow as one of those misfeatures of C which by some mysterious force of the universe can never be fixed.

Boolean types

Posted Apr 28, 2014 16:29 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> Right, in my program logic I have two cases, but if I am writing code that takes an int then the type signature (or function contract) does nothing to convey to me, the compiler, or other programmers that only two values are expected.
Well, use “typedef enum { False, True } Bool” then. Well, actually, don't, because boolean parameters are a code smell anyway:
http://www.nickhodges.com/post/How-Not-To-Code-2-Dont-Use...

Boolean types

Posted Apr 26, 2014 23:19 UTC (Sat) by nix (subscriber, #2304) [Link]

It appears I'm searching an outdated draft of C99 (IIRC, bool revisions were made very late, which probably explains this). My primary copy appears to have vanished some time ago and I never noticed: I'll have to retrieve it from an offsite backup :(

I clearly shouldn't be trying to look up stuff in language standards while on hefty doses of codeine, I overlook obvious stuff like the date at the top... codeine is not good for codeing, as it were...