Re: [dev] [dwm][st] why use ints over bools?

[Mattias Andrée]

On Fri, 21 Jun 2024 23:29:29 +0200
Storkman  wrote:

> On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote:
> > On Fri, 21 Jun 2024 21:14:19 +0200
> > Markus Wichmann  wrote:
> >   
> > > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић:  
> > > > Given that, why complicate code by introducing a separate, superfluous,
> > > > type?
> > > 
> > > Let me offer a counterpoint: Expressiveness. If I make a function return
> > > a bool, then everyone from the world's worst junior dev to Ken Thompson
> > > himself will be able to see at the very first glance that the function
> > > is returning a boolean value. If I make a function return an int, that
> > > is not so clear.  
> > 
> > Expressiveness is great, but _Bool is more than just an expression of
> > intent. If _Bool was nothing more than a typedef of int, it would be great.
> > 
> > However, in the real world, I also find that boolean isn't expressive enough
> > and enum is needed. This is because people do silly things like returning
> > true or false, without it being obvious that the function should even return
> > anything at all,  
> 
> Doesn't the function having a return type make it obvious that it returns 
> something?

Yes, but apart from that. If you just look at the name, 

> 
> > do indicate for example if the function was successful,
> > or the action was completed or need to be made again, or if the action
> > modified the stated (could be true if the state was not modified or true
> > if the state was not modified).  
> 
> If I have a function like "bool is_cromulent(foo)", I'd expect it to return
> true when foo IS cromulent (or 1 if the return type is int).
> Are you saying it should return cromulence_t with values either
> IS_CROMULENT or IS_NOT_CROMULENT?

No, I'm talking about bad code.

What would you expect "bool applyConfiguration(conf)" to return?

Maybe it returns true on success and false on failure.
Maybe it returns true the state was modified and false otherwise.

> 
> > > [...] Not so long ago, this very list opined that C89 is the only true
> > > C standard [...]  
> 
> If there was a new poll, I demand a recount!
> 

Re: [dev] [dwm][st] why use ints over bools?

[stefan11111]

În 22 iunie 2024 00:10:52 EEST, "Страхиња Радић"  a 
scris:
>Дана 24/06/21 09:14PM, Markus Wichmann написа:
>> Isn't it all about familiarity in the end? Or can you articulate what
>> parts of C11 and C23 you find objectionable?
>
>Just a few examples:
>
>- C11: bounds checking interfaces (now even suggested for removal)
>   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
>- C23: nullptr{_t,}, true/false, _BigInt, "C++ compatibility" - just no.
>   https://harmful.cat-v.org/software/c++/
>
>The overarching trend seems to be that C is gradually turning into C++ 
>lite with all the keywords, attributes, etc. There's no need for any of 
>that.
>

Imo, the "new" C standard smells c++.
At this rate, we might even see class
become a keyword in C.

I see no reason to add even more keywords and
types that nobody asked for(nullptr/nullptr_t).
Some, like true and false can break existing
code which already uses those as
variables/functions.

As someone else said in this thread, maybe the
worst addition is the fact that void foo() is now
the same as void foo(void), which was a very
useful feature.

However, even worse IMO is the fact that gcc
devs have started breaking perfectly good code
since gcc14.
-- 
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math 
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans -fno-plt 
-fno-semantic-interposition -falign-functions=64 -fgraphite-identity 
-floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto libressl 
olde-gentoo asm native-symlinks threads jit jumbo-build minimal strip 
system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd 
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /lib/udev 
/usr/share/icons /usr/share/applications /usr/share/gtk-3.0/emoji 
/usr/lib64/palemoon/gtk2"

Re: [dev] [dwm][st] why use ints over bools?

[Storkman]

On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote:
> On Fri, 21 Jun 2024 21:14:19 +0200
> Markus Wichmann  wrote:
> 
> > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић:
> > > Given that, why complicate code by introducing a separate, superfluous,
> > > type?  
> > 
> > Let me offer a counterpoint: Expressiveness. If I make a function return
> > a bool, then everyone from the world's worst junior dev to Ken Thompson
> > himself will be able to see at the very first glance that the function
> > is returning a boolean value. If I make a function return an int, that
> > is not so clear.
> 
> Expressiveness is great, but _Bool is more than just an expression of
> intent. If _Bool was nothing more than a typedef of int, it would be great.
> 
> However, in the real world, I also find that boolean isn't expressive enough
> and enum is needed. This is because people do silly things like returning
> true or false, without it being obvious that the function should even return
> anything at all,

Doesn't the function having a return type make it obvious that it returns 
something?

> do indicate for example if the function was successful,
> or the action was completed or need to be made again, or if the action
> modified the stated (could be true if the state was not modified or true
> if the state was not modified).

If I have a function like "bool is_cromulent(foo)", I'd expect it to return
true when foo IS cromulent (or 1 if the return type is int).
Are you saying it should return cromulence_t with values either
IS_CROMULENT or IS_NOT_CROMULENT?

> > [...] Not so long ago, this very list opined that C89 is the only true
> > C standard [...]

If there was a new poll, I demand a recount!

-- 
Storkman

Re: [dev] [dwm][st] why use ints over bools?

[Страхиња Радић]

Дана 24/06/21 09:14PM, Markus Wichmann написа:
> Let me offer a counterpoint: Expressiveness. If I make a function return
> a bool, then everyone from the world's worst junior dev to Ken Thompson
> himself will be able to see at the very first glance that the function
> is returning a boolean value. If I make a function return an int, that
> is not so clear.

Maybe a "junior dev" who learned to program in Java or C# would only be 
able to see it if _Bool was used instead of int, but the rest of the 
world is (idiomatically and intuitively - knowing that logical type in 
C is int and how it is usually used, aside from deducing from the name 
of the function itself) going to have no problem understanding that

int isalpha(int c);

returns 0 if the parameter c is not a letter, and !=0 otherwise, and 
that it perfectly plugs into if-constructs:

if (!isalpha(s[i]))
// ...

This is one of those places where C is closer to machine code/assembler 
than, say, level of abstraction (obscurity) of Pascal or Java.


> Isn't it all about familiarity in the end? Or can you articulate what
> parts of C11 and C23 you find objectionable?

Just a few examples:

- C11: bounds checking interfaces (now even suggested for removal)
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
- C23: nullptr{_t,}, true/false, _BigInt, "C++ compatibility" - just no.
   https://harmful.cat-v.org/software/c++/

The overarching trend seems to be that C is gradually turning into C++ 
lite with all the keywords, attributes, etc. There's no need for any of 
that.

Re: [dev] [dwm][st] why use ints over bools?

[Mattias Andrée]

On Fri, 21 Jun 2024 21:14:19 +0200
Markus Wichmann  wrote:

> Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић:
> > Given that, why complicate code by introducing a separate, superfluous,
> > type?  
> 
> Let me offer a counterpoint: Expressiveness. If I make a function return
> a bool, then everyone from the world's worst junior dev to Ken Thompson
> himself will be able to see at the very first glance that the function
> is returning a boolean value. If I make a function return an int, that
> is not so clear.

Expressiveness is great, but _Bool is more than just an expression of
intent. If _Bool was nothing more than a typedef of int, it would be great.

However, in the real world, I also find that boolean isn't expressive enough
and enum is needed. This is because people do silly things like returning
true or false, without it being obvious that the function should even return
anything at all, do indicate for example if the function was successful,
or the action was completed or need to be made again, or if the action
modified the stated (could be true if the state was not modified or true
if the state was not modified).

> 
> That said, if a function returns bool and is longer than one or two
> statements, it is probably already doing something wrong. I have seen
> bool used as error code, and it is such a missed opportunity to return
> an enum of error codes to say what actually went wrong.
> 
> > Every new iteration of C after C99 introduced more unnecessary cruft.
> > C99 is the best version, although it has its rough edges, one of which
> > is the _Bool type.
> >  
> 
> All versions of C after C89 added more stuff that wasn't there before.
> That is mostly the point. You cannot remove things without introducing
> an incompatibility. So the only thing I can remember that was ever
> removed was gets(), which was a bad idea from the start, and finally
> removed in C11.
> 
> I don't know, to me statements like "C99 is the best version" are always
> funny. Not so long ago, this very list opined that C89 is the only true
> C standard and everything that came after is "not C", as I recall. Which
> is literally wrong, of course (C is whatever WG14 says it is, whether
> you like it or not).
> 
> Isn't it all about familiarity in the end? Or can you articulate what
> parts of C11 and C23 you find objectionable?

C99 added a lot of good features. And just a couple of questionable features:
//, , and intermingled declarations and code. So this was a very good
improvement

C95 added digraphs, , and the not-too-well-designed  and
, which aren't that commonly used; so while making some
improvements, this wasn't the best of improvements.

I think C11 really brought some nice improvements, but you don't need them too
often, so C99 is often enough: _Aliasas, _Alignof, aligned_alloc, _Thread_local,
_Atomic, anonymous nested structs and unions, _Generic. It also adds a lot of
things that I could take or leave. There's nothing to objectionable in C11, even
if things code be better designed.

C17 only addressed defects in C11, so this version is completely 
non-objectionable.

C23 really does add some nice things that have been missing, but most often them
don't actually have to be a part of C. One thing I really do like about C23 is
__VA_OPT__. I don't see with we need nullptr, nullptr_t and _BigInt looks like a
big design blunder. I find changing the meaning of the auto keyword, and to a
lesser extent making true, false, alignas, alignof, bool, static_assert, and
thread_local keywords, objectionable. While not technically objectionable, I
personally find the [[ ]]-syntax for attributes unstylish. But worst of all 
might
be making `int foo()` equivalent to `int foo(void)`.

> 
> Ciao,
> Markus
> 

Re: [dev] [dwm][st] why use ints over bools?

[Markus Wichmann]

Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић:
> Given that, why complicate code by introducing a separate, superfluous,
> type?

Let me offer a counterpoint: Expressiveness. If I make a function return
a bool, then everyone from the world's worst junior dev to Ken Thompson
himself will be able to see at the very first glance that the function
is returning a boolean value. If I make a function return an int, that
is not so clear.

That said, if a function returns bool and is longer than one or two
statements, it is probably already doing something wrong. I have seen
bool used as error code, and it is such a missed opportunity to return
an enum of error codes to say what actually went wrong.

> Every new iteration of C after C99 introduced more unnecessary cruft.
> C99 is the best version, although it has its rough edges, one of which
> is the _Bool type.
>

All versions of C after C89 added more stuff that wasn't there before.
That is mostly the point. You cannot remove things without introducing
an incompatibility. So the only thing I can remember that was ever
removed was gets(), which was a bad idea from the start, and finally
removed in C11.

I don't know, to me statements like "C99 is the best version" are always
funny. Not so long ago, this very list opined that C89 is the only true
C standard and everything that came after is "not C", as I recall. Which
is literally wrong, of course (C is whatever WG14 says it is, whether
you like it or not).

Isn't it all about familiarity in the end? Or can you articulate what
parts of C11 and C23 you find objectionable?

Ciao,
Markus

Re: [dev] [dwm][st] why use ints over bools?

[Страхиња Радић]

Дана 24/06/20 10:24PM, sewn написа:
> Sure, but why?

It is part of the suckless coding style. Since st is a suckless 
project, it follows the suckless coding style.

* * *

I can't speak for those who wrote the suckless coding standard, but 
as a bystander, I can give this observation.

If the question is what is the reasoning behind not using `bool` (or, 
more accurately, `_Bool`, since `bool` is a macro defined in stdbool.h) 
type in suckless coding style:

- The result of logical operators, such as !, &&, || and relational 
  operators, such as <, <=, >, >= is explicitly int in C99 anyway 
  (check the actual text of the standard if you don't believe me), with 
  possible values 0 and 1

- The type of `expression` in:

if (expression) statement
if (expression) statement else statement

  in C99 is "scalar" with value tested for 0 - if unequal, `statement`
  following `if` is executed, if equal, statement following `else` is
  executed.

Given that, why complicate code by introducing a separate, superfluous, 
type? Major compilers, such as GCC and Clang/LLVM, are competent enough 
to optimize for speed or size as needed anyway.

Every new iteration of C after C99 introduced more unnecessary cruft. 
C99 is the best version, although it has its rough edges, one of which 
is the _Bool type.

Re: [dev] [dwm][st] why use ints over bools?

[sewn]

On 2024-06-15 22:06, Страхиња Радић wrote:


Дана 24/06/15 11:54AM, Zac написа:

I'm curious why you use ints though. Because bools are 31 bits smaller 
than
ints, which is 31 bits of memory saved. Not that 31 bits is very much, 
but

still...


https://suckless.org/coding_style/


Tests and Boolean Values

* Do not use C99 bool types (stick to integer types).

* Otherwise use compound assignment and tests unless the line grows 
too long:


if (!(p = malloc(sizeof(*p
hcf();


Sure, but why?

Re: [dev] [dwm][st] why use ints over bools?

[Markus Wichmann]

Am Sat, Jun 15, 2024 at 06:10:50PM +0200 schrieb Vincent Lefevre:
> IMHO, this has been poorly designed. There should have been a macro
> taking a parameter N (an integer constant expression), where the
> type would have been valid for any N up to the maximum width (thus
> at least 64). For portability, the existence of the macro could have
> also been tested with #ifdef, allowing a fallback.

Well, there is INT_LEAST${N}_MAX from stdint.h, telling you that type
int_least${n}_t exists. And C23 has the new _BitInt(N) types, if that
helps any.

Of course, you can also just face up to reality and notice that you will
likely never work on a machine with CHAR_BIT != 8, and even if you do,
it will be unlikely to have CHAR_BIT % 8 != 0. Therefore, any
int_least${n}_t with $n % 8 != 0 is unlikely to exist.

Ciao,
Markus

Re: [dev] [dwm][st] why use ints over bools?

[NRK]

> There should have been a macro taking a parameter N (an integer
> constant expression), where the type would have been valid for any N
> up to the maximum width (thus at least 64). For portability, the
> existence of the macro could have also been tested with #ifdef,
> allowing a fallback.

I don't think this is a good idea at all. A huge majority of "fallback"
code I see in realworld are riddled with bugs - because no one tests
those path - and the more ifdefs you have the faster your software
becomes untestable because each ifdef increases the build combination by
an exponetial factor.

"But how can specifying minimum width lead to bugs"? Integer promotion
rules.

uint16_t a = UINT16_MAX;
uint16_t b = 1;
int c = a + b;   // what is the value of c ??

Is the value of `c` 0 due to unsigned wraparound? Or is it 2^16 because
of integer promotion? You don't know unless you know the rank and width
of `int` for that platform.

Any nontrivial software will contain thousands if not millions of
arithmetic operations. Trying to babysit each arithmetic operations for
"theoretical portability" is not only a massive waste of time, it's very
likely buggy as well unless you can actually test it.

So unless you know for certain that you will be targetting weird
machines and have the means to test on it: keep it simple and make
things *obviously correct* instead of overcomplicating things for
"theoretical portability".

- NRK

Re: [dev] [dwm][st] why use ints over bools?

[Mattias Andrée]

On Sat, 15 Jun 2024 16:16:14 +0200
Mattias Andrée  wrote:

> You will save between 0 and 3 bytes on common platforms,
> and those 3− bytes will probably be allocated and wasted anyway.
> Is it worth it?
> 
> It's absolutely better than _Bool, but I don't think there
> is any point in using char over int. All common operations
> (this may exclude division and modulo) supported on int,
> by definition, that same is not true for char. Say for example
> that, want to check if the value is non-zero. Using it, this
> will probably entail performing some operation on the value
> and than duing a jump conditioned on a flag register. With
> more narrow types, this may (not the case on x86-64) require

The x86-64 instruction set doesn't require type promotion,
but the CPU may still require it, and although I'm not certain,
I think x86-64 CPU does perform type promotion in these
cases. It should at least be fair to say that less complex
CPU will do this to avoid implementing all different operations
for all the different type, and CPU's may also avoid it and instead
favour type promotion in order to improve parallellism.

> that value to first be promoted to int.
> 
> 
> On Sat, 15 Jun 2024 17:05:27 +0300
> stefan1  wrote:
> 
> > What about using char's then?
> > 
> > În 15 iunie 2024 15:36:16 EEST, "Mattias Andrée"  a scris: 
> >  
> > >I have some general issues with _Bool:
> > >
> > >Arithmetic or bitwise operations on _Bool is subject to type promotion
> > >making them rather pointless.
> > >
> > >With also be a problem if they were not, as you than couldn't sum of 
> > >_Bool's
> > >to find how many were set (commonly this we be to detect if more than 1 was
> > >set).
> > >
> > >It is implementation-define which signness _Bool has, meaning, I don't know
> > >if it will be promoted to a signed or an unsigned int.
> > >
> > >_Bool is only useful to make sure that a non-zero value is converted to the
> > >value 1. And if this is absolutely necessarily, you should make this 
> > >explicit,
> > >e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
> > >overhead to ensure that the value is always 1 or 0. And despite all this,
> > >you can mess up and get _Bool's with a non-boolean value.
> > >
> > >It is implementation-defined how wide a _Bool is.
> > >
> > >_Bool will be at least the size of a byte, if you really want it to be a 
> > >bit
> > >if you have many of them, you can use bit fields or good old names values 
> > >to
> > >store multiple boolean values in one int. Generally you don't gain any real
> > >savings by using a single byte type instead of an int if you only one or 
> > >two
> > >booleans.
> > >
> > >Basically, I like things to be explicit and well-defined.
> > >
> > >
> > >
> > >On Sat, 15 Jun 2024 11:54:02 +
> > >Zac  wrote:
> > >
> > >> In a number of spots in dwm and st I've seen the use of integers as 
> > >> booleans. e.g.
> > >> - dwm.c line 95, 140, 1870
> > >> - drw.c line 252
> > >> - st.c line 44, 48
> > >> 
> > >> That's not an extensive list; just some examples.
> > >> 
> > >> I'm curious why you use ints though. Because bools are 31 bits smaller 
> > >> than ints, which is 31 bits of memory saved. Not that 31 bits is very 
> > >> much, but still...
> > >> 
> > >
> > >
> >   
> 
> 

Re: [dev] [dwm][st] why use ints over bools?

[Страхиња Радић]

Дана 24/06/15 11:54AM, Zac написа:
> I'm curious why you use ints though. Because bools are 31 bits smaller than 
> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
>still...

https://suckless.org/coding_style/

> Tests and Boolean Values
>
> * Do not use C99 bool types (stick to integer types).
>
> * Otherwise use compound assignment and tests unless the line grows too long:
>
> if (!(p = malloc(sizeof(*p
>   hcf();

Re: [dev] [dwm][st] why use ints over bools?

[Vincent Lefevre]

On 2024-06-15 16:24:38 +0200, Mattias Andrée wrote:
> No, you should use [u]int_least1_t, except that probably doesn't
> exist,

So, you must not use it. :)

On the opposite, int_least8_t is a *required* type in ISO C99+.
That's why I've proposed it.

> I think C actually should add some what to specify
> [u]int_{least,fast}N_t for arbitrary N. It could be simple as
> libc having to enumerate all up to some N. But it's a bit silly
> that [u]int_{least,fast}N_t (expecially [u]int_leastN_t) exists
> only for 8, 16, 32, and 64, when the machine probably has integers
> with those exact widths anyways.

IMHO, this has been poorly designed. There should have been a macro
taking a parameter N (an integer constant expression), where the
type would have been valid for any N up to the maximum width (thus
at least 64). For portability, the existence of the macro could have
also been tested with #ifdef, allowing a fallback.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [dev] [dwm][st] why use ints over bools?

[Mattias Andrée]

No, you should use [u]int_least1_t, except that probably doesn't
exist, so char is best as it is per definition the most narrow type,
and if the signness is important you can specify it.

I think C actually should add some what to specify
[u]int_{least,fast}N_t for arbitrary N. It could be simple as
libc having to enumerate all up to some N. But it's a bit silly
that [u]int_{least,fast}N_t (expecially [u]int_leastN_t) exists
only for 8, 16, 32, and 64, when the machine probably has integers
with those exact widths anyways.


On Sat, 15 Jun 2024 16:14:58 +0200
Vincent Lefevre  wrote:

> On 2024-06-15 17:05:27 +0300, stefan1 wrote:
> > What about using char's then?  
> 
> char may be signed or unsigned. I would suggest unsigned char or
> signed char, or better, (u)int_least8_t.
> 

Re: [dev] [dwm][st] why use ints over bools?

[Mattias Andrée]

You will save between 0 and 3 bytes on common platforms,
and those 3− bytes will probably be allocated and wasted anyway.
Is it worth it?

It's absolutely better than _Bool, but I don't think there
is any point in using char over int. All common operations
(this may exclude division and modulo) supported on int,
by definition, that same is not true for char. Say for example
that, want to check if the value is non-zero. Using it, this
will probably entail performing some operation on the value
and than duing a jump conditioned on a flag register. With
more narrow types, this may (not the case on x86-64) require
that value to first be promoted to int.


On Sat, 15 Jun 2024 17:05:27 +0300
stefan1  wrote:

> What about using char's then?
> 
> În 15 iunie 2024 15:36:16 EEST, "Mattias Andrée"  a scris:
> >I have some general issues with _Bool:
> >
> >Arithmetic or bitwise operations on _Bool is subject to type promotion
> >making them rather pointless.
> >
> >With also be a problem if they were not, as you than couldn't sum of _Bool's
> >to find how many were set (commonly this we be to detect if more than 1 was
> >set).
> >
> >It is implementation-define which signness _Bool has, meaning, I don't know
> >if it will be promoted to a signed or an unsigned int.
> >
> >_Bool is only useful to make sure that a non-zero value is converted to the
> >value 1. And if this is absolutely necessarily, you should make this 
> >explicit,
> >e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
> >overhead to ensure that the value is always 1 or 0. And despite all this,
> >you can mess up and get _Bool's with a non-boolean value.
> >
> >It is implementation-defined how wide a _Bool is.
> >
> >_Bool will be at least the size of a byte, if you really want it to be a bit
> >if you have many of them, you can use bit fields or good old names values to
> >store multiple boolean values in one int. Generally you don't gain any real
> >savings by using a single byte type instead of an int if you only one or two
> >booleans.
> >
> >Basically, I like things to be explicit and well-defined.
> >
> >
> >
> >On Sat, 15 Jun 2024 11:54:02 +
> >Zac  wrote:
> >  
> >> In a number of spots in dwm and st I've seen the use of integers as 
> >> booleans. e.g.
> >> - dwm.c line 95, 140, 1870
> >> - drw.c line 252
> >> - st.c line 44, 48
> >> 
> >> That's not an extensive list; just some examples.
> >> 
> >> I'm curious why you use ints though. Because bools are 31 bits smaller 
> >> than ints, which is 31 bits of memory saved. Not that 31 bits is very 
> >> much, but still...
> >>   
> >
> >  
> 

Re: [dev] [dwm][st] why use ints over bools?

[Vincent Lefevre]

On 2024-06-15 17:05:27 +0300, stefan1 wrote:
> What about using char's then?

char may be signed or unsigned. I would suggest unsigned char or
signed char, or better, (u)int_least8_t.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [dev] [dwm][st] why use ints over bools?

[stefan11111]

What about using char's then?

În 15 iunie 2024 15:36:16 EEST, "Mattias Andrée"  a scris:
>I have some general issues with _Bool:
>
>Arithmetic or bitwise operations on _Bool is subject to type promotion
>making them rather pointless.
>
>With also be a problem if they were not, as you than couldn't sum of _Bool's
>to find how many were set (commonly this we be to detect if more than 1 was
>set).
>
>It is implementation-define which signness _Bool has, meaning, I don't know
>if it will be promoted to a signed or an unsigned int.
>
>_Bool is only useful to make sure that a non-zero value is converted to the
>value 1. And if this is absolutely necessarily, you should make this explicit,
>e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
>overhead to ensure that the value is always 1 or 0. And despite all this,
>you can mess up and get _Bool's with a non-boolean value.
>
>It is implementation-defined how wide a _Bool is.
>
>_Bool will be at least the size of a byte, if you really want it to be a bit
>if you have many of them, you can use bit fields or good old names values to
>store multiple boolean values in one int. Generally you don't gain any real
>savings by using a single byte type instead of an int if you only one or two
>booleans.
>
>Basically, I like things to be explicit and well-defined.
>
>
>
>On Sat, 15 Jun 2024 11:54:02 +
>Zac  wrote:
>
>> In a number of spots in dwm and st I've seen the use of integers as 
>> booleans. e.g.
>> - dwm.c line 95, 140, 1870
>> - drw.c line 252
>> - st.c line 44, 48
>> 
>> That's not an extensive list; just some examples.
>> 
>> I'm curious why you use ints though. Because bools are 31 bits smaller than 
>> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
>> still...
>> 
>
>

-- 
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math 
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans -fno-plt 
-fno-semantic-interposition -falign-functions=64 -fgraphite-identity 
-floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto libressl 
olde-gentoo asm native-symlinks threads jit jumbo-build minimal strip 
system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd 
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /lib/udev 
/usr/share/icons /usr/share/applications /usr/share/gtk-3.0/emoji 
/usr/lib64/palemoon/gtk2"

Re: [dev] [dwm][st] why use ints over bools?

[Mattias Andrée]

I have some general issues with _Bool:

Arithmetic or bitwise operations on _Bool is subject to type promotion
making them rather pointless.

With also be a problem if they were not, as you than couldn't sum of _Bool's
to find how many were set (commonly this we be to detect if more than 1 was
set).

It is implementation-define which signness _Bool has, meaning, I don't know
if it will be promoted to a signed or an unsigned int.

_Bool is only useful to make sure that a non-zero value is converted to the
value 1. And if this is absolutely necessarily, you should make this explicit,
e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
overhead to ensure that the value is always 1 or 0. And despite all this,
you can mess up and get _Bool's with a non-boolean value.

It is implementation-defined how wide a _Bool is.

_Bool will be at least the size of a byte, if you really want it to be a bit
if you have many of them, you can use bit fields or good old names values to
store multiple boolean values in one int. Generally you don't gain any real
savings by using a single byte type instead of an int if you only one or two
booleans.

Basically, I like things to be explicit and well-defined.



On Sat, 15 Jun 2024 11:54:02 +
Zac  wrote:

> In a number of spots in dwm and st I've seen the use of integers as booleans. 
> e.g.
> - dwm.c line 95, 140, 1870
> - drw.c line 252
> - st.c line 44, 48
> 
> That's not an extensive list; just some examples.
> 
> I'm curious why you use ints though. Because bools are 31 bits smaller than 
> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
> still...
> 

Re: [dev] [dwm][st] why use ints over bools?

[Pontus Stenetorp]

On Sat 15 Jun 2024, Zac wrote:
> 
> In a number of spots in dwm and st I've seen the use of integers as booleans. 
> e.g.
> - dwm.c line 95, 140, 1870
> - drw.c line 252
> - st.c line 44, 48
> 
> That's not an extensive list; just some examples.
> 
> I'm curious why you use ints though. Because bools are 31 bits smaller than 
> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
> still...

You may want to refer to a textbook or make an online search about that 
assumption. On every architecture I have worked with, it would be *at least* a 
byte.

[dev] [dwm][st] why use ints over bools?

[Zac]

In a number of spots in dwm and st I've seen the use of integers as booleans. 
e.g.
- dwm.c line 95, 140, 1870
- drw.c line 252
- st.c line 44, 48

That's not an extensive list; just some examples.

I'm curious why you use ints though. Because bools are 31 bits smaller than 
ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
still...