2022-02-07 at 09:13 +0100, Mateusz Viste wrote:
> 2022-02-07 at 09:11 +0100, Mateusz Viste wrote:
> > 2022-02-06 at 22:08 +0000, Vir Campestris wrote:
> > > bool lets the compiler pick a type where the architecture can
> > > store 2 values easily.
> > >
> > > int_fast8_t is only convenient on machines that have hardware
> > > byte support. OK, that's most of them, but by no means all.
> >
> > int_fast8_t is convenient on machines that have hardware support for
> > anything that is at least 8 bits large.
> ^^
> (should have been "16" obviously) :)

(no it shouldn't, I will stop posting before the morning coffee now)

Mateusz

Mateusz Viste <mateusz@xyz.invalid> writes:

> 2022-02-04 at 00:36 -0800, Tiib wrote:
>
>> That bool has only two values was already said above. It feels
>> tautological that more constrained type brings less opportunities
>> of misuse and so less cases to check or to unit test. I do not
>> know why it is not perceived as an advantage by some people or why
>> they get offended like if they were accused or suspected of misuse
>> by providing such benefit.
>
> You are right of course. Having an emulated "1-bit" type is, in
> theory, providing a nice way to handle values that are expected to
> be binary in nature.
>
> What I am wondering about is the practical use of it - ie. in
> what kind of situation such _Bool type could save the day. I am
> certainly biased, since I always used normal integer to keep
> flags, so I am genuinely interested to see how other people do.
> [...]

Consider the following code excerpt

enum {
FLAG_X = 1,
FLAG_Y = 2,
FLAG_Z = 4,
... etc ...
};

...

unsigned flags;

...

if( flags & FLAG_Y ) .. something ...

The purpose of _Bool is to hold the value of an expression in
just the same way that the expression would give in a logical
context such as if(), while(), do ... while(), or the middle
expression of for(). If for some reason we want to reuse or
hold on to the value of the expression inside an if() test,
using _Bool provides a good way to do that:

_Bool flag_y = flags & FLAG_Y;

I am something of an "old school" C programmer. If 'p' is a
pointer variable, I don't mind writing (and in fact often
prefer writing)

if( p ) ...

rather than the more verbose

if( p != NULL ) ...

Using _Bool works here too:

_Bool p_valid = p;

The conversion to _Bool converts null pointers to 0, and non-null
pointers to 1.

One reason we might want to save logical values in a variable is
to be able to combine logical expressions conveniently, without
needing to write out the '!= 0' that is implicit in logical
contexts. Also, because each _Bool is guaranteed to hold either
0 or 1 and nothing else, they can be combined using &, ^, and |
(if that is wanted) rather than && and || (and who knows what for
exclusive or). Of course I'm a big fan of && and ||, and tend to
use them more often than the bitwise & and |, but occasionally &,
^, and | do a better job of conveying how I think about the
conditions involved.

Another situation where I have found _Bool useful is inside
structs that hold lots of logical values. Rather use ordinary
members, logical values can be held in _Bool bitfields:

struct whatever {
_Bool property_a : 1;
_Bool property_b : 1;
_Bool property_c : 1;
/* etc */
};

Bitfields of type _Bool have the same "logical value" behavior
that regular _Bool variables have, namely converting any scalar
quantity to _Bool gives 1 if the converted quantity compares
not equal to 0, and 0 otherwise.

IME _Bool works well for most variables that are meant to hold a
logical value. Moreover if _Bool is not used then there is the
awkward question of what type to use instead. I wouldn't go so
far as to say that _Bool should be used for all such variables
and without exception, but in most cases it does seem to provide
a better fit than the other integer types.

On 07/02/2022 08:52, Tim Rentsch wrote:

> Using _Bool works here too:
>
> _Bool p_valid = p;
>
> The conversion to _Bool converts null pointers to 0, and non-null
> pointers to 1.

This leads to:

_Bool b;

b = &b;

which looks unintuitive. Usually the LHS would be of type T, then the
RHS would have the incompatible type T*

Bart <bc@freeuk.com> writes:

> On 07/02/2022 08:52, Tim Rentsch wrote:
>
>> Using _Bool works here too:
>> _Bool p_valid = p;
>> The conversion to _Bool converts null pointers to 0, and non-null
>> pointers to 1.
>
> This leads to:
>
> _Bool b;
>
> b = &b;
>
> which looks unintuitive. Usually the LHS would be of type T, then the
> RHS would have the incompatible type T*

That's an unwarranted intuition:

void *p;
p = &p;

--
Ben.

On 07/02/2022 11:22, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 07/02/2022 08:52, Tim Rentsch wrote:
>>
>>> Using _Bool works here too:
>>> _Bool p_valid = p;
>>> The conversion to _Bool converts null pointers to 0, and non-null
>>> pointers to 1.
>>
>> This leads to:
>>
>> _Bool b;
>>
>> b = &b;
>>
>> which looks unintuitive. Usually the LHS would be of type T, then the
>> RHS would have the incompatible type T*
>
> That's an unwarranted intuition:
>
> void *p;
> p = &p;

OK, there's that, although at least both sides are pointers to
something. A void target on either side makes both targets compatible.

I first came across this behaviour of _Bool in code that I think was
passing the address of a struct to a function expecting a _Bool
argument. It was rather puzzling (apart from the fact that the address
of a struct instance would always be true).

An explicit conversion (for example using !! on the argument, where the
0/1 result is a more reasonable value to pass to a _Bool parameter)
would have made things clearer.

Bart <bc@freeuk.com> writes:

> On 07/02/2022 08:52, Tim Rentsch wrote:
>
>> Using _Bool works here too:
>>
>> _Bool p_valid = p;
>>
>> The conversion to _Bool converts null pointers to 0, and non-null
>> pointers to 1.
>
> This leads to:
>
> _Bool b;
>
> b = &b;
>
> which looks unintuitive. Usually the LHS would be of type T, then the
> RHS would have the incompatible type T*

It is querelis gratia querimonia as usual, I see.

(With apologies to my high school Latin teacher. I never
was good at Latin.)

On 07/02/2022 08:11, Mateusz Viste wrote:
> 2022-02-06 at 22:08 +0000, Vir Campestris wrote:
>> bool lets the compiler pick a type where the architecture can store 2
>> values easily.
>>
>> int_fast8_t is only convenient on machines that have hardware byte
>> support. OK, that's most of them, but by no means all.
>
> int_fast8_t is convenient on machines that have hardware support for
> anything that is at least 8 bits large. I imagine that on a machine
> like the one you describe (no bytes, words only) int_fast8_t would be a
> word.
>
... which means using 64 bits for each boolean. If you cared about space
you'd probably use a bitmask.

bool tells the compiler what you are going to put in it.

The compiler optimisation settings tell the compiler whether you care
about speed or size.

As I said originally it's entirely valid for the compiler to put a bunch
of bools into a bitmask (as long as you never ask for their address!)
but it can't do that if you've insisted that it store at least 8 bits.

Andy

2022-02-07 at 21:42 +0000, Vir Campestris wrote:
> > int_fast8_t is convenient on machines that have hardware support for
> > anything that is at least 8 bits large. I imagine that on a machine
> > like the one you describe (no bytes, words only) int_fast8_t would
> > be a word.
> >
> .. which means using 64 bits for each boolean. If you cared about
> space you'd probably use a bitmask.

If I cared about space, then I'd probably use a simple char, because a
bitmask might actually end up taking more space than using a single
byte. If we really are that much space-constrained, then it is
important to also account for all the extra shifting, ANDing and ORing
operations that the program will have to contain for handling the
bitmask each time a flag is accessed.

> bool tells the compiler what you are going to put in it.
>
> The compiler optimisation settings tell the compiler whether you care
> about speed or size.

That's delegation. And it's fine, but whatever the compiler chooses to
do is not guaranteed to be what I want... esp. in the extreme context
you suggest (ie. a program so space-constrained that one needs to count
every bit of memory).

> As I said originally it's entirely valid for the compiler to put a
> bunch of bools into a bitmask (as long as you never ask for their
> address!) but it can't do that if you've insisted that it store at
> least 8 bits.

Bitmasks are cool, but not for the reason you mentioned - at least not
from my point of view. I like bitmasks because I find them to be an
elegant and convenient way of passing many flags to a function with a
single argument and still having nice, self-explanatory names (while
not cluttering the function call with all the flags I am not passing).
Having the compiler store bools inside a bitmask is a debatable
feature... We do not get the advantage of function call clarity that a
bitmask provides, but do have its drawbacks (slower to access and more
code required).

Mateusz

(Sorry for delay, I just found this somehow went in a file folder
instead of outbox)

On Fri, 04 Feb 2022 21:14:59 -0800, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote:

> Mateusz Viste <mateusz@xyz.invalid> writes:
> > so let me ask: what C99 feature do you use, that you wouldn't want
> > to loose?
....
> First there are several constructs that C89/C90 permits but are
> disallowed in C99:
....
> * 'return' statements need not give an expression in a
> function that returns a non-void type, and conversely
>
> I understand why K&R C (and later C89/C90) allowed these things.
....
Not conversely. return expr in void function was a constraint
violation in C89/90. (And impossible in K&R which had no void.)

On 2/4/2022 9:14 PM, Tim Rentsch wrote:
>
> First there are several constructs that C89/C90 permits but are
> disallowed in C99:
>
> * calls to functions not previously declared are implicitly
> declared (with nothing known about the parameter types, and
> as returning type 'int')

True.

> * declarations (especially functions) are allowed not to give
> a type specifier, in which case the type defaults to 'int'

With one remark: in C89/90 a declaration has to specify at least one
declaration-specifier, which is a storage-class-specifier,
type-specifier or a type-qualifier. Declarations that have none are
illegal in C89/90

/* File scope */
foo(); /* this is not a valid declaration */
const bar(); /* this is a valid declaration, implicit `int` */
static baz(); /* this is a valid declaration, implicit `int` */

The only exception from this rule is function *definitions*, which are
governed by a separate branch of grammar

qux() {} /* this is a valid definition, implicit `int` */

> * 'return' statements need not give an expression in a
> function that returns a non-void type, and conversely

True, but not the "conversely" part. Supplying an expression to a
`return` statement in a `void` function is a constraint violation.

>
> Number 4: variadic macros. Compare this fragment
>
> case 1: case 2: case 3: case 4:
> case 5: case 6: case 7: case 8: case 9:
>
> with this fragment
>
> cases(1,2,3,4,5,6,7,8,9):

Well, the latter is a constraint violation in all versions of standard
C. Comma operator is not allowed in constant expressions. It is C++ that
lifted that restriction, but in C it still stands.

--
Best regards,
Andrey

On 5/14/2022 12:04 PM, Andrey Tarasevich wrote:
>> Number 4: variadic macros.  Compare this fragment
>>
>>      case 1: case 2: case 3: case 4:
>>      case 5: case 6: case 7: case 8: case 9:
>>
>> with this fragment
>>
>>      cases(1,2,3,4,5,6,7,8,9):
>
> Well, the latter is a constraint violation in all versions of standard
> C. Comma operator is not allowed in constant expressions. It is C++ that
> lifted that restriction, but in C it still stands.

Oh... My mistake. Apparently I misunderstood what was being said. You
mean that `cases` is a macro that unfolds into a bunch of separate
`case` labels. Got it. No problems then.

I missed the fact that it is spelled as `cases`. I misread it as

case (1,2,3,4,5,6,7,8,9):

which would be legal in modern C++, but not in C.

--
Best regards,
Andrey

dave_thompson_2@comcast.net writes:

> (Sorry for delay, I just found this somehow went in a file folder
> instead of outbox)
>
> On Fri, 04 Feb 2022 21:14:59 -0800, Tim Rentsch
> <tr.17687@z991.linuxsc.com> wrote:
>
>> Mateusz Viste <mateusz@xyz.invalid> writes:
>>
>>> so let me ask: what C99 feature do you use, that you wouldn't want
>>> to loose?
>
> ...
>
>> First there are several constructs that C89/C90 permits but are
>> disallowed in C99:
>
> ...
>
>> * 'return' statements need not give an expression in a
>> function that returns a non-void type, and conversely
>>
>> I understand why K&R C (and later C89/C90) allowed these things.
>
> ...
> Not conversely. return expr in void function was a constraint
> violation in C89/90. (And impossible in K&R which had no void.)

Thank you for the follow-up (and no worries about the delay).

To the best of my knowledge all of the following are true
statements.

K&R C did not have a void type (although some pre-standard C
compilers may have had support for void).

In both the ANSI C standard (C89) and the first ISO C standard
(C90), a return statement with an expression is a constraint
violation if it appears in a function whose return type is void
(although some pre-standard C compilers may not have observed
this rule).

K&R C, C89, and C90 all allow things like this:

int
f(){
...
return;
}

g(){
...
return 0;
}

In the ISO C99 standard, paragraph 5 in the Foreword says (in
part) the following:

This second edition cancels and replaces the first edition,
ISO/IEC 9899:1990, as amended and corrected by ISO/IEC
9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and ISO/IEC
9899/COR2:1996. Major changes from the previous edition
include:

[...]

-- return without expression not permitted in function
that returns a value (and vice versa)

I hope these observations clarify my earlier comment.

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 2/4/2022 9:14 PM, Tim Rentsch wrote:
>
>> First there are several constructs that C89/C90 permits but are
>> disallowed in C99:
>>
>> * calls to functions not previously declared are implicitly
>> declared (with nothing known about the parameter types, and
>> as returning type 'int')
>
> True.
>
>> * declarations (especially functions) are allowed not to give
>> a type specifier, in which case the type defaults to 'int'
>
> With one remark: in C89/90 a declaration has to specify at least
> one declaration-specifier, [...]

Yes, the statement is only about type specifiers, not other
declaration specifiers.

>> * 'return' statements need not give an expression in a
>> function that returns a non-void type, and conversely
>
> True, but not the "conversely" part. Supplying an expression to a
> return` statement in a `void` function is a constraint violation.

A post from Dave Thompson gave this same observation, and I have
just now responded to his posting.