Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

> should really be a bool

bool is actually #define bool _Bool. You have to include <stdbool.h> to get it. That's ugly enough not to want to use it.

I'm looking at the April 2023 draft of ISO C. Under "Relational Expressions" I see that the result of an expression like x < y isn't bool, but ... int.

Here is the exact wording, minus a footnote reference:

Each of the operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.

int is still the Boolean type in C, and null pointers and zeros are still falsy, relational expressions yield 0 or 1 of type int, and #define bool is just a sham for anal retentives.

> typedefs ending with _t are reserved for standards extensions

That is inaccurate. It's POSIX that reserves this namespace. Even if you're targeting POSIX, the reservation has next to no practical meaning, and can safely be ignored.

Here is why. What POSIX says is that when new type names will be introduced in the future in POSIX, they will have _t as a suffix. Well, so what? New type names in ISO C will also have _t suffixes, yet ISO C doesn't say anything about that being "reserved".

When a new identifier is introduced, it has to start and end in something.

Whenever POSIX introduces a new public identifier in the future, that identifier will either start with "a", or else with "b", or with "c" ... does that mean that we should stop using all identifiers in order not to tread on a reserved space?

When you have a language without namespaces/packages, you just live with the threat of a clash and deal with it when it happens.

Name clashes are not just with standards like ISO C and POSIX but vendor extensions and third-party code.

The mole is only a problem when it rears its head, and that's when you whack it.

> bool is actually #define bool _Bool. You have to include <stdbool.h> to get it. That's ugly enough not to want to use it.

Sure, which is why it got changed to a keyword in C23. I'll agree this should have happened earlier.

The return type of comparison operators is entirely irrelevant; you don't build APIs by reference to the return type of a comparison operator. It makes a difference to the reader whether your source code says "int" or "bool", that alone is all the reason anyone should need.

> That is inaccurate. It's POSIX that reserves this namespace.

You got me there. However, the question is, why would you add the _t? It serves no purpose. Typedefs have their own namespace anyway, you're not working around some possible collision by adding the _t.

That said I've already noted this is a commonly ignored aspect. I suppose it "feels" better/correct to some readers. I will happily agree this is the weakest point of my feedback either way, yet I still rather point it out and have people learn more details about this.

> The return type of comparison operators is entirely irrelevant

It is entirely relevant. The boolean type of the language is whatever is the type of (0 < 1).

> Typedefs have their own namespace anyway

Typedefs positively do not have their own namespace.

If you write

  #undef getc
  {
     typedef char getc;

  }

you cannot call the getc function in that scope; it is now the typedef.

When folks talk about namespaces, structs, & typedefs in C, it's to call out that `struct X` and `typedef int X;` can both exist at the same time. In other words, nothing prevents one from doing a `typedef struct X { int f; } X;` or similar, using `X` as the name in both places.

It is true that it's more correct to say "struct names have their own namespace", though I think we can infer what's actually meant here fairly easily.

> more correct to say "struct names have their own namespace"

That is false. If we declare an "enum foo", which is not a struct, then we cannot have a "struct foo" in that scope.

Sure, you're right, it's just not really relevant here.

Well, your two comments set a standard for relevance that is not easily attained by others.

> int is still the Boolean type in C, and null pointers and zeros are still > falsy, relational expressions yield 0 or 1 of type int, and #define bool > is just a sham for anal retentives.

Alternatively, and especially in a library API, using bool is a clear specification of semantics.

An int parameter could have many meanings. An int return value similarly. In both cases, using "bool" makes the usage instantly more clear, without the need for comments, or man pages, or Doxygen, or super_long_parameter_names, or whatever.

I think it's useful.

What about size of stored bool variable? Just using int will take 4 bytes (Or something else, but still bigger then 1), while stdbool will only use 1 byte, no?

In arrays, you can use char. In structs, there are also bitfields like unsigned flag : 1.

Reply on news.ycombinator.com