2022-02-03 at 10:24 -0800, Tim Rentsch wrote:
> > Now, about features that I don't like in C99:
> > - VLAs (temptation argument again, that may lead to stack
> > exhaustion)
> > - bool (don't see what added value this brings)
> > - complex & imaginary numbers (I admit those may be useful in some
> > niche usage, but *I* never had such need)
>
> With all due respect, these sound more like rationalizations than
> reasons.

These are my reasons, I'm sorry to disappoint.

> If you don't give C99 an earnest try of non-trivial duration,
> you'll never know.

It's not like I reject C99 completely - I do use it in a few projects,
mainly for bad reasons (to name two: extensive use of VLAs, looked nice
and fun when I started using it, and by the time I realized that's a
trap it was too late - the cost of redoing things the proper way is too
high now so I'm living with it now ; second is 3rd-party code that
insists on using [0]-sized arrays and mixes variable declaration with
code).

Anyway - I do use C99 from time to time on some oddball projects, but
for my daily stuff I simply don't feel it brings anything on top of
what I have already with gnu89. But maybe I missed some key things, so
let me ask: what C99 feature do you use, that you wouldn't want to
loose?

Mateusz

Mateusz Viste <mateusz@xyz.invalid> writes:
[...]
> It's not like I reject C99 completely - I do use it in a few projects,
> mainly for bad reasons (to name two: extensive use of VLAs, looked nice
> and fun when I started using it, and by the time I realized that's a
> trap it was too late - the cost of redoing things the proper way is too
> high now so I'm living with it now ; second is 3rd-party code that
> insists on using [0]-sized arrays and mixes variable declaration with
> code).

C99 doesn't support zero-sized arrays. Attempting to define a
zero-sized ordinary array is a constraint violation. Creating a
zero-sized VLA has undefined behavior.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

2022-02-03 at 13:33 -0800, Keith Thompson wrote:
> C99 doesn't support zero-sized arrays.

You are right indeed, 0-sized arrays are a GNU extension. Seems I
misremembered this one.

Mateusz

On 03/02/2022 20:34, Mateusz Viste wrote:
> what C99 feature do you use, that you wouldn't want to
> loose?

I mostly use C++.

I use bool all the time; why would you use anything else? It's a type
that holds 2 values, and the compiler can pick what to use for your
processor. It might be a bit mask, or a 64 bit word. It might even vary
with your optimisation settings.

Andy

2022-02-03 at 22:28 +0000, Vir Campestris wrote:
> I use bool all the time; why would you use anything else? It's a type
> that holds 2 values, and the compiler can pick what to use for your
> processor. It might be a bit mask, or a 64 bit word. It might even
> vary with your optimisation settings.

Can you tell what advantage it has over using, say, int_fast8_t?

Mateusz

On 2/3/22 17:48, Mateusz Viste wrote:
> 2022-02-03 at 22:28 +0000, Vir Campestris wrote:
>> I use bool all the time; why would you use anything else? It's a type
>> that holds 2 values, and the compiler can pick what to use for your
>> processor. It might be a bit mask, or a 64 bit word. It might even
>> vary with your optimisation settings.
>
> Can you tell what advantage it has over using, say, int_fast8_t?

Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
standard 7.3.14), type always generate only one of two possible values,
which is what you need for true boolean semantics. That if very
definitely not the case for int_fast8_t.

On 2/3/22 15:34, Mateusz Viste wrote:
....
> let me ask: what C99 feature do you use, that you wouldn't want to
> loose?

Many of the new features that I especially like are related to floating
point operations, which is of special interest to me because I've
specialized in scientific computer programming. I've marked those with
asterisks below. But the rest would be of interest to me pretty much
regardless of what kind of programming I was doing. Paragraph 5 of the
forward to C99 summarizes the changes from C90. These are the ones I
particularly like:

— more precise aliasing rules via effective type
— restricted pointers
— variable length arrays
— flexible array members
— static and type qualifiers in parameter array declarators
— complex (and imaginary) support in <complex.h>*
— remove implicit int
— reliable integer division
— hexadecimal floating-point constants and %a and %A printf/scanf
conversion specifiers*
— compound literals
— designated initializers
— // comments
— extended integer types and library functions in <inttypes.h> and
<stdint.h>
— remove implicit function declaration
— mixed declarations and code
— new block scopes for selection and iteration statements
— additional math library functions in <math.h> *
— treatment of error conditions by math library functions
(math_errhandling )*
— floating-point environment access in <fenv.h>*
— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support*
— the snprintf family of functions in <stdio.h>
— standard pragmas*
— _ _func_ _ predefined identifier
— additional strftime conversion specifiers
— relaxed constraints on aggregate and union initialization
— return without expression not permitted in function that returns a
value (and vice versa)

On Friday, 4 February 2022 at 05:17:33 UTC+2, james...@alumni.caltech.edu wrote:
> On 2/3/22 17:48, Mateusz Viste wrote:
> > 2022-02-03 at 22:28 +0000, Vir Campestris wrote:
> >> I use bool all the time; why would you use anything else? It's a type
> >> that holds 2 values, and the compiler can pick what to use for your
> >> processor. It might be a bit mask, or a 64 bit word. It might even
> >> vary with your optimisation settings.
> >
> > Can you tell what advantage it has over using, say, int_fast8_t?
> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
> standard 7.3.14), type always generate only one of two possible values,
> which is what you need for true boolean semantics. That if very
> definitely not the case for int_fast8_t.

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.

2022-02-03 at 22:17 -0500, James Kuyper wrote:
> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
> standard 7.3.14), type always generate only one of two possible
> values, which is what you need for true boolean semantics. That if
> very definitely not the case for int_fast8_t.

int_fast8_t (just like any other integer type) can be either zero or
non-zero. Why does the exact value of "not zero" matter to you? I mean,
what kind of practical problems can be solved with _Bool?

Mateusz

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.

My usual need for "booleans" is storing flags. I do this then:

int flag_zorgl;
const char *s = read_string_from_space();

flag_zorgl = is_zorgl_present(s);
(...)
if (flag_zorgl) process_str_with_a_zorgl(s);
(...)
if (!flag_zorgl) no_zorgl_data_processing(s);

The above could very well use a _Bool. But would it be significantly
faster? Shorter? Safer? What I am looking for is a tangible example of
_Bool's added value in a practical situation.

It's worth noting that in the above code is_zorgl_present() could be
replaced by count_zorgls(), which would provide more information to the
program, without affecting the "boolean-like" operations. This is, of
course, an advantage only if the program requires such extra
information.

One scenario I can think of where _Bool would work better, is if
someone does this kind of things:

/* do something that require zorgl or other but not both */
if (flag_zorgl ^ flag_other) process(s);

This is an example I came up with only in a effort of trying to find a
rationalization for _Bool, it's not something I recall ever needing. If
I'd had needed it, I'd have to put some safeguards around values in
flags, or write a much longer form:

if (((flag_zorgl) && (!flag_other)) || ((!flag_zorgl) && (flag_other)))
{ process(s);
}

....or alternatively I could use an enum of two values to simulate a
bool. Either way it would be more hassle than _Bool. But again - it is
not something I recall ever needing. Are there other examples that
would be less hypothetical?

Mateusz

On 04/02/2022 09:44, Mateusz Viste wrote:
> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>> standard 7.3.14), type always generate only one of two possible
>> values, which is what you need for true boolean semantics. That if
>> very definitely not the case for int_fast8_t.
>
> int_fast8_t (just like any other integer type) can be either zero or
> non-zero. Why does the exact value of "not zero" matter to you? I mean,
> what kind of practical problems can be solved with _Bool?
>

There are, I think, two main differences here.

First is the logical one. A "bool" is a type that can be either "true"
or "false". This is clearer, simpler, and more closely models the
programmer's intent than storing a 0 or a 1 in a small integer type. If
I read :

bool isThingValid(const thing * p)

I know the result will be either "true" or "false".

If I read:

int_fast8_t isThingValid(const thing * p)

I am left wondering if the thing might be partially valid, with a scale.
I wonder /why/ the programmer wanted an arithmetic integer type aimed
at high-speed small integer ranges. Will the function always return 0
or 1? Does it consider non-zero as "true" ? Is it going to give a
negative value if there is an error? Did the programmer really want to
use an enumerated type but is converting to int_fast8_t to save space
somehow?

Prior to C99, it was extremely common in C programming to define your
own Boolean type. Mostly this was done by something like:

typedef int bool;
#define true 1
#define false 0

But sometimes signed or unsigned char was used, sometimes an enumerated
type, sometimes slightly different names or capitalisations were used.
A few would give different values for "true" and "false" (I've never
really understood why). Some would define "true" as "(0 == 0)" or
similar, in the mistaken belief that the result might vary by compiler.

It is hugely simpler, clearer and more portable to stick to the one
standard type.

Secondly, there are technical differences. The conversion of an integer
"x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
"b" is either 0 or 1 - and the compiler can use that knowledge for
optimisation (as can the programmer). This can mean some operations
(such as conversion from an integer) may be less efficient, but other
operations (such as logical operations) are more efficient. Overall, it
is usually a win.

Of course you can write your C code without ever needing the type _Bool.
But you can write /better/ code, in a clearer, easier and more
efficient manner if you use it when appropriate.

(In C++, "bool" and its distinction from other integer types is hugely
more important.)

On Friday, 4 February 2022 at 10:06:42 UTC, David Brown wrote:
> On 04/02/2022 09:44, Mateusz Viste wrote:
> > 2022-02-03 at 22:17 -0500, James Kuyper wrote:
> >> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
> >> standard 7.3.14), type always generate only one of two possible
> >> values, which is what you need for true boolean semantics. That if
> >> very definitely not the case for int_fast8_t.
> >
> > int_fast8_t (just like any other integer type) can be either zero or
> > non-zero. Why does the exact value of "not zero" matter to you? I mean,
> > what kind of practical problems can be solved with _Bool?
> >
> There are, I think, two main differences here.
>
> First is the logical one. A "bool" is a type that can be either "true"
> or "false". This is clearer, simpler, and more closely models the
> programmer's intent than storing a 0 or a 1 in a small integer type. If
> I read :
>
> bool isThingValid(const thing * p)
>
> I know the result will be either "true" or "false".
>
>
> If I read:
>
> int_fast8_t isThingValid(const thing * p)
>
> I am left wondering if the thing might be partially valid, with a scale.
> I wonder /why/ the programmer wanted an arithmetic integer type
>
Yes. If a function returns values that are logically either true/false, then the
best way to document this is to return a boolean.

However if it takes values which are either true.false, then you have this
problem

void SetSpinEdit(SpinEdit *control, double value, bool clamp, bool roundtoprecison, bool propagatemessage);

All looks reasonable. A SpinEdit is obviously some GUI widget that displays a real value. The second parameter
is the value it is set to. "clamp" must mean that the control has "maximum" and "minimum" values and
we want to honour those in case our value is out of range. "roundtoprecision" probably means that
the control show, for example, two places after the decimal point, and if we pass 1.234 we expect "1.23"
to be displayed and the internal value to be as close to 1.23 as floating point will allow. "propagatemessage"
probaby means that the control has a callback associated with it when the user enters a value, and we want
that callback to be called.

However when you see this.

double height = fabs(maximumvalue(x, N));
// Maintainer's comment. Bug in this test here ?
if (height != GetSpinEdit(height_spn))
SetSpnEdit(height_spn, height, true, false, false);

It's far less obvious what is going on.

On 04/02/2022 14:53, Malcolm McLean wrote:
> On Friday, 4 February 2022 at 10:06:42 UTC, David Brown wrote:
>> On 04/02/2022 09:44, Mateusz Viste wrote:
>>> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>>>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>>>> standard 7.3.14), type always generate only one of two possible
>>>> values, which is what you need for true boolean semantics. That if
>>>> very definitely not the case for int_fast8_t.
>>>
>>> int_fast8_t (just like any other integer type) can be either zero or
>>> non-zero. Why does the exact value of "not zero" matter to you? I mean,
>>> what kind of practical problems can be solved with _Bool?
>>>
>> There are, I think, two main differences here.
>>
>> First is the logical one. A "bool" is a type that can be either "true"
>> or "false". This is clearer, simpler, and more closely models the
>> programmer's intent than storing a 0 or a 1 in a small integer type. If
>> I read :
>>
>> bool isThingValid(const thing * p)
>>
>> I know the result will be either "true" or "false".
>>
>>
>> If I read:
>>
>> int_fast8_t isThingValid(const thing * p)
>>
>> I am left wondering if the thing might be partially valid, with a scale.
>> I wonder /why/ the programmer wanted an arithmetic integer type
>>
> Yes. If a function returns values that are logically either true/false, then the
> best way to document this is to return a boolean.
>
> However if it takes values which are either true.false, then you have this
> problem
>
> void SetSpinEdit(SpinEdit *control, double value, bool clamp, bool roundtoprecison, bool propagatemessage);
>
> All looks reasonable. A SpinEdit is obviously some GUI widget that displays a real value. The second parameter
> is the value it is set to. "clamp" must mean that the control has "maximum" and "minimum" values and
> we want to honour those in case our value is out of range. "roundtoprecision" probably means that
> the control show, for example, two places after the decimal point, and if we pass 1.234 we expect "1.23"
> to be displayed and the internal value to be as close to 1.23 as floating point will allow. "propagatemessage"
> probaby means that the control has a callback associated with it when the user enters a value, and we want
> that callback to be called.
>
> However when you see this.
>
> double height = fabs(maximumvalue(x, N));
> // Maintainer's comment. Bug in this test here ?
> if (height != GetSpinEdit(height_spn))
> SetSpnEdit(height_spn, height, true, false, false);
>
> It's far less obvious what is going on.
>

That is a completely separate issue, and nothing to do with the
question, which was "what advantages are there to using _Bool over an
plain integer type?".

Yes, it's hard to see what

SetSpnEdit(height_spn, height, true, false, false);

is doing. But you don't make anything better by writing

SetSpnEdit(height_spn, height, 1, 0, 0);

We could discuss ways to handle such paramaters in a clearer or less
error-prone way, but that would be a completely different discussion and
there is little in the improvements of C99 over C90 that affect it.

2022-02-04 at 15:27 +0100, David Brown wrote:
> That is a completely separate issue, and nothing to do with the
> question, which was "what advantages are there to using _Bool over an
> plain integer type?".

I think that in a vicious way, it is not separate.

> Yes, it's hard to see what
> SetSpnEdit(height_spn, height, true, false, false);
>
> is doing. But you don't make anything better by writing
> SetSpnEdit(height_spn, height, 1, 0, 0);

If I would be a user of _Bool, I'd be very tempted to use the first form
(and end up with a hardly readable line). Since I do not use _Bool,
I prefer doing this:

#define FLAG_SETSPN_CLAMP 0x01
#define FLAG_SETSPN_ROUNDTOPREC 0x02
#define FLAG_SETSPN_PROPAGMSG 0x04

SetSpnEdit(height_spn, height, FLAG_SETSPN_CLAMP);

You will say that the same can be done with having _Bool available (and
not using it, in this specific case), and you will be obviously right.
I guess it's a vicious side effect of the human mind - "if I have a
hammer, then everything looks like nails". :-)

Mateusz

On 2/4/22 03:44, Mateusz Viste wrote:
> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>> standard 7.3.14), type always generate only one of two possible
>> values, which is what you need for true boolean semantics. That if
>> very definitely not the case for int_fast8_t.
>
> int_fast8_t (just like any other integer type) can be either zero or
> non-zero. Why does the exact value of "not zero" matter to you? I mean,
> what kind of practical problems can be solved with _Bool?

I'm far more interested in there being only one representation of
"true", than I am in how it's represented. If you misuse an ordinary
integer type as a substitute for a true boolean type, then equality and
inequality comparisons for that type aren't guaranteed to behave
properly - and that can be a problem. A simple comparison b1==b2, should
return a result of "true" if, and only if, both b1 and b2 are true, but
that would not be guaranteed if you misuse an ordinary integer type as
if it were a boolean type, because it might be the case that b1==3 and
b2==5.

Less importantly, in almost all cases _Bool values get implicitly
promoted to 'int'. You can take advantage of the fact that the resulting
conversion is guaranteed to produce a value of 1 if the value is true,
to write arithmetic expressions involving boolean values that could
break if you're misusing an ordinary integer type as if it were boolean.
5*b1 + 3*b2 should have a value of either 0, 3, 5, or 8, but that
wouldn't be guaranteed with an ordinary integer type.

Mateusz Viste <mateusz@xyz.invalid> writes:
>2022-02-03 at 22:28 +0000, Vir Campestris wrote:
>> I use bool all the time; why would you use anything else? It's a type
>> that holds 2 values, and the compiler can pick what to use for your
>> processor. It might be a bit mask, or a 64 bit word. It might even
>> vary with your optimisation settings.
>
>Can you tell what advantage it has over using, say, int_fast8_t?

half as many characters to type, and more precisely identifies function.

On Friday, 4 February 2022 at 16:07:12 UTC, james...@alumni.caltech.edu wrote:
> On 2/4/22 03:44, Mateusz Viste wrote:
> > 2022-02-03 at 22:17 -0500, James Kuyper wrote:
> >> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
> >> standard 7.3.14), type always generate only one of two possible
> >> values, which is what you need for true boolean semantics. That if
> >> very definitely not the case for int_fast8_t.
> >
> > int_fast8_t (just like any other integer type) can be either zero or
> > non-zero. Why does the exact value of "not zero" matter to you? I mean,
> > what kind of practical problems can be solved with _Bool?
> I'm far more interested in there being only one representation of
> "true", than I am in how it's represented.
>
In C, true also means "exists". This is very idiomatic:
void whizzystringfunction(char *str)
{ if (str)
{
// we've been passed a string, do our whizzy things with it
}
}

On Friday, 4 February 2022 at 11:50:11 UTC+2, Mateusz Viste wrote:
> 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.

It is typically used to store, to return and to pass separate truth
values. I suspect you know that:

device->allows_cellular_connection = true; // store
if (is_authenticated(user)) { /*... */ } // return
set_visibility(separator, false); // pass

> My usual need for "booleans" is storing flags. I do this then:
>
> int flag_zorgl;
> const char *s = read_string_from_space();
>
> flag_zorgl = is_zorgl_present(s);
> (...)
> if (flag_zorgl) process_str_with_a_zorgl(s);
> (...)
> if (!flag_zorgl) no_zorgl_data_processing(s);

Yes that was what I meant. We can easily use int or char or enum type
for that flag_zorgl but then we just have doubt if it is worth to put a
debug check here or there or if it is worth to write unit tests for cases
when it has some other value than 0 or 1.

assert(flag_zorgl == 0 || flag_zorgl == 1);

>
> The above could very well use a _Bool. But would it be significantly
> faster? Shorter? Safer? What I am looking for is a tangible example of
> _Bool's added value in a practical situation.
>
> It's worth noting that in the above code is_zorgl_present() could be
> replaced by count_zorgls(), which would provide more information to the
> program, without affecting the "boolean-like" operations. This is, of
> course, an advantage only if the program requires such extra
> information.

My review would require rename ... flag_zorgl containing count of those
would be confusing. Also instead of if(count_zorgls(s)) I would
prefer if (count_zorgls(s)>0) or if (count_zorgls(s)!=0) as those
are more logical to read and each of us has huge displays
and can type 2-3 characters in blink of eye.

> One scenario I can think of where _Bool would work better, is if
> someone does this kind of things:
>
> /* do something that require zorgl or other but not both */
> if (flag_zorgl ^ flag_other) process(s);
>
> This is an example I came up with only in a effort of trying to find a
> rationalization for _Bool, it's not something I recall ever needing. If
> I'd had needed it, I'd have to put some safeguards around values in
> flags, or write a much longer form:
>
> if (((flag_zorgl) && (!flag_other)) || ((!flag_zorgl) && (flag_other)))
> {
> process(s);
> }

Huh? C does have logical and && and logical or || but logical
xor ^^ seems missing. Why? Because != can be used as logical xor.
But with ints where 42 means also true it looks bit weird:

if ( !flag_zorgl != !!flag_other ) process(s);

>
> ...or alternatively I could use an enum of two values to simulate a
> bool. Either way it would be more hassle than _Bool. But again - it is
> not something I recall ever needing. Are there other examples that
> would be less hypothetical?

No. For me the clear reasons are already sufficient:
1) the type conveys to reader of code that it has only two values
2) no one raises questions about need of checking if it is really so
3) compilers and programmers can find opportunities to optimise
thanks to that fact.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2/4/22 03:44, Mateusz Viste wrote:
>> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>>> standard 7.3.14), type always generate only one of two possible
>>> values, which is what you need for true boolean semantics. That if
>>> very definitely not the case for int_fast8_t.
>>
>> int_fast8_t (just like any other integer type) can be either zero or
>> non-zero. Why does the exact value of "not zero" matter to you? I mean,
>> what kind of practical problems can be solved with _Bool?
>
> I'm far more interested in there being only one representation of
> "true", than I am in how it's represented. If you misuse an ordinary
> integer type as a substitute for a true boolean type, then equality and
> inequality comparisons for that type aren't guaranteed to behave
> properly - and that can be a problem. A simple comparison b1==b2, should
> return a result of "true" if, and only if, both b1 and b2 are true, but
> that would not be guaranteed if you misuse an ordinary integer type as
> if it were a boolean type, because it might be the case that b1==3 and
> b2==5.

Quibble: b1==b2 is true iff b1 and b2 are both true *or* they're both
false.

[...]

> Less importantly, in almost all cases _Bool values get implicitly
> promoted to 'int'. You can take advantage of the fact that the resulting
> conversion is guaranteed to produce a value of 1 if the value is true,
> to write arithmetic expressions involving boolean values that could
> break if you're misusing an ordinary integer type as if it were boolean.
> 5*b1 + 3*b2 should have a value of either 0, 3, 5, or 8, but that
> wouldn't be guaranteed with an ordinary integer type.

A perhaps more plausible example of that:

int widget_count = 0;
widget_count += has_foo_widget;
widget_count += has_bar_widget;
...

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 04/02/2022 10:06, David Brown wrote:
> On 04/02/2022 09:44, Mateusz Viste wrote:
>> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>>> standard 7.3.14), type always generate only one of two possible
>>> values, which is what you need for true boolean semantics. That if
>>> very definitely not the case for int_fast8_t.
>>
>> int_fast8_t (just like any other integer type) can be either zero or
>> non-zero. Why does the exact value of "not zero" matter to you? I mean,
>> what kind of practical problems can be solved with _Bool?
>>
>
> There are, I think, two main differences here.
>
> First is the logical one. A "bool" is a type that can be either "true"
> or "false". This is clearer, simpler, and more closely models the
> programmer's intent than storing a 0 or a 1 in a small integer type. If
> I read :
>
> bool isThingValid(const thing * p)
>
> I know the result will be either "true" or "false".
>
>
> If I read:
>
> int_fast8_t isThingValid(const thing * p)
>
> I am left wondering if the thing might be partially valid, with a scale.
> I wonder /why/ the programmer wanted an arithmetic integer type aimed
> at high-speed small integer ranges. Will the function always return 0
> or 1? Does it consider non-zero as "true" ? Is it going to give a
> negative value if there is an error? Did the programmer really want to
> use an enumerated type but is converting to int_fast8_t to save space
> somehow?
>
> Prior to C99, it was extremely common in C programming to define your
> own Boolean type. Mostly this was done by something like:
>
> typedef int bool;
> #define true 1
> #define false 0
>
> But sometimes signed or unsigned char was used, sometimes an enumerated
> type, sometimes slightly different names or capitalisations were used.
> A few would give different values for "true" and "false" (I've never
> really understood why). Some would define "true" as "(0 == 0)" or
> similar, in the mistaken belief that the result might vary by compiler.
>
> It is hugely simpler, clearer and more portable to stick to the one
> standard type.
>
>
> Secondly, there are technical differences. The conversion of an integer
> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
> "b" is either 0 or 1 - and the compiler can use that knowledge for
> optimisation (as can the programmer). This can mean some operations
> (such as conversion from an integer) may be less efficient, but other
> operations (such as logical operations) are more efficient. Overall, it
> is usually a win.

You're never really quite sure what's happening with _Bool.

There's little control over its size. And in A program like this:

union {
_Bool a;
unsigned char b;
} x;

x.b=0x55;
printf("A= %X\n", x.a);
printf("B= %X\n", x.b);

if (x.a == true) puts("A is True");
if (x.a == false) puts("A is False");
if (x.a != true && x.a != false) puts("A is neither True nor False");

different compilers show different results, including this from gcc -O0:

A= 55
B= 55
A is True
A is False
A is neither True nor False

MSVC shows this:

A= 55
B= 55
A is neither True nor False

while Clang, and gcc -O3, displays:

A= 1
B= 55
A is True

You can probably claim this is due to UB or whatever, but the fact
remains that using regular int types, the results will be consistent and
predictable across all compilers. It /is/ possible for the byte value
that usually represents a bool type to be set something that is neither
true (1) or false (0).

On 2/4/22 14:12, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>> I'm far more interested in there being only one representation of
>> "true", than I am in how it's represented. If you misuse an ordinary
>> integer type as a substitute for a true boolean type, then equality and
>> inequality comparisons for that type aren't guaranteed to behave
>> properly - and that can be a problem. A simple comparison b1==b2, should
>> return a result of "true" if, and only if, both b1 and b2 are true, but
>> that would not be guaranteed if you misuse an ordinary integer type as
>> if it were a boolean type, because it might be the case that b1==3 and
>> b2==5.
>
> Quibble: b1==b2 is true iff b1 and b2 are both true *or* they're both
> false.

Correct. There's only one false value, either way, so I was thinking
mainly about the true values, and as a result worded my statement
incorrectly.

>> Less importantly, in almost all cases _Bool values get implicitly
>> promoted to 'int'. You can take advantage of the fact that the resulting
>> conversion is guaranteed to produce a value of 1 if the value is true,
>> to write arithmetic expressions involving boolean values that could
>> break if you're misusing an ordinary integer type as if it were boolean.
>> 5*b1 + 3*b2 should have a value of either 0, 3, 5, or 8, but that
>> wouldn't be guaranteed with an ordinary integer type.
>
> A perhaps more plausible example of that:
>
> int widget_count = 0;
> widget_count += has_foo_widget;
> widget_count += has_bar_widget;

Agreed - that is a more plausible thing to do.

Mateusz Viste <mateusz@xyz.invalid> writes:

> 2022-02-03 at 10:24 -0800, Tim Rentsch wrote:

[...]

>> If you don't give C99 an earnest try of non-trivial duration,
>> you'll never know.
>
> [...] I do use C99 from time to time on some oddball projects, but
> for my daily stuff I simply don't feel it brings anything on top of
> what I have already with gnu89. But maybe I missed some key things,
> so let me ask: what C99 feature do you use, that you wouldn't want
> to loose?

I see this as two or three related questions, which I will try to
answer in turn. The third of these relates to the question of
using option -std=gnuXX versus option -std=cXX, and is addressed
in the last section.

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')

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

* '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.
But they are all dangerous, especially implicit declaration of
functions, and it is good that C99 requires them to be flagged.

Second, there are lots of C99 additions (my list has at least 20)
that I find useful. These span a range of utility but in each
case either they offer something that is at best very inconvenient
to do in C89/C90 or that is only a minor convenience but one I
have gotten used to and would not want to give up. Here is a
selected subset, in rough order of increasing significance:

Number 10: 'enum' definitions allow a trailing comma. Only a
convenience feature, but a useful one, and it makes the language
more regular by aligning with the analogous rule for array
initializers.

Number 9: array parameters may have 'static' and 'const' etc.
Normally I use array notation (eg, 'int x[]') for parameters
that are treated as arrays rather than as pointers to single
objects. This feature allows length and qualifier information to
be added to the pointer parameter while still retaining array
notation in the parameter declaration.

Number 8: 'va_copy' macro. I found 'va_copy' indispensable
while implementing an extension to printf().

Number 7: 'long long' type (and library functions). It's nice to
have an integer type that is guaranteed to be at least 64 bits,
which C89/C90 doesn't have.

Number 6: snprintf and friends. Needed for safe formatting.

Number 5: restricted pointers. Especially when a function has
parameters that are pointers to characters, 'restrict' can help a
lot with quality of generated code (because of aliasing concerns).

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):

Variadic macros make writing a 'cases()' macro possible (and of
course there are other applications as well). I /write/ variadic
macros not very often, but I often see situations where /applying/
a variadic macro can make the code cleaner and neater.

Number 3: variably modified types. Variable length arrays are
sometimes problematic because of the danger of stack overflow.
But variably modified types, which are akin to VLAs but not the
same, provide similar benefits without the associated risk of
blowing the stack.

Number 2: non-constant block-level initializers for structs and
arrays. In C89/C90 initializers for structs and array must have
constant values for each element, including variables that are
function locals. In C99 this limitation is removed, avoiding the
need to do element-by-element assignment for what is logically
just an initialization.

Number 1: compound literals and designated initializers. I put
these two features together because they are often used together
and because there is some synergy between them. Individually, a
compound literal is often a safer alternative to casting, and
designated initializers provide an easy way of initializing a
sparse array (provided "sparse" means most of the elements are
zero). There are of course other applications but the last
sentence gives a couple of common examples.

I find myself using most of the features in the above list (not
all certainly, but more than half) in almost every C program I
work on.

Third area: on the matter of -std=gnuXX versus -std=cXX.

Many years ago I didn't pay much attention to differences between
gnu C and ISO standard C. Little by little I became aware of the
distinction and what some implications are of using one versus
using the other.

One key difference is that when using standard C you know what
you're getting. To say that another way, standard C can be
counted on to be the same across different platforms. Conversely
it is frustrating to take a program that compiles under gnu C
on one platform but doesn't on a different platform. I have seen
this result a lot more often than I would like.

A second key difference is that what "gnu C" means can (and
unfortunately sometimes does) change over time. Standard C
doesn't have that property (assuming of course we are sticking to
one version of the ISO C standard, such as C99).

I understand that some programs need access to functionality that
simply is not available if compiling as strictly standard C. In
such cases the use of non-standard options cannot be avoided, but
it can be localized. If and when problems come up, they will be
easier to deal with by virtue of being confined to a relatively
small and well-defined part of the program.

In times past I had a more laissez faire attitude toward allowing
non-standard compiler options. What changed my mind was being
bitten when something would work in one place or time and then
not work in another place or time. Using strictly standard C is
reliable and dependable, and that is worth a lot. Sometimes it
is necessary to make a (local) pragmatic exception to that rule,
and that's fine, but it's better for program structure and
reliability that such cases be exceptions rather than the usual
choice.

2022-02-04 at 21:14 -0800, Tim Rentsch wrote:
> I see this as two or three related questions, which I will try to
> answer in turn.

Thanks for the time you took to answer this in such a well-structured
and concise way. Much appreciated.

> 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')

That's a problem only in theory, because in practice compilers warn
about it anyway. At least these that I use do (gcc and clang, with -Wall
-pedantic). Such program:

int main(void) { return(poo(1)); }
int poo(kupa) { return(kupa); }

Triggers a warning with both gcc and clang, in both std=c89 and std=c99
(in all cases I use the -Wall flag, as I always do with all my code):

poo.c:1:25: warning: implicit declaration of function ‘poo’

Hence, while I agree with you on the theoretical annoyance of implicit
function declaration, it does not appear to be a practical concern.

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

Same story as above. gcc and clang both emit this, in both c89 and c99
modes with -pedantic:

for unspecified function type:
poo.c:2:1: warning: return type defaults to ‘int’

for unspecified parameter type:
poo.c:2:9: warning: parameter 'kupa' was not declared, defaulting to
type 'int'

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

I have to admit I didn't know about that. But again, compilers
warn about this in both c89 and c99 modes:

clang (warns even without any extra warning flags):
poo.c:2:18: warning: non-void function does not return a value

gcc (requires -Wall):
poo.c:2:1: warning: control reaches end of non-void function

The function I tested was simply this:
int poo(kupa) { }

> Number 10: 'enum' definitions allow a trailing comma. Only a
> convenience feature, but a useful one

I think it is nice only because it limits the amount of changed lines
when adding a new value at the end of the list, so an svn diff is one
line shorter. But then I always wonder: did the programmer forgot about
some terminating entry, or did he leave this useless comma there on
purpose?

> Number 9: array parameters may have 'static' and 'const' etc.
> Normally I use array notation (eg, 'int x[]') for parameters
> that are treated as arrays rather than as pointers to single
> objects. This feature allows length and qualifier information to
> be added to the pointer parameter while still retaining array
> notation in the parameter declaration.

I am not sure I understand this one (and I also never use array
notation in function parameters). Are you referring to such construct?

void pupa(const char s[]) {
printf("%c", s[0]);
}

Apparently this passes without warnings in both c89 and c99 modes of
clang and gcc. But I probably misunderstood you.

> Number 8: 'va_copy' macro. I found 'va_copy' indispensable
> while implementing an extension to printf().

I never needed this, but this certainly depends on the kind of programs
one writes. Anyway, va_copy() is part of gnu89.

> Number 7: 'long long' type (and library functions). It's nice to
> have an integer type that is guaranteed to be at least 64 bits,
> which C89/C90 doesn't have.

I agree, and I routinely use int64_t types in c89 mode (requires
including stdint.h).

> Number 6: snprintf and friends. Needed for safe formatting.

Agreed, I use them very often. They are part of gnu89.

> Number 5: restricted pointers. Especially when a function has
> parameters that are pointers to characters, 'restrict' can help a
> lot with quality of generated code (because of aliasing concerns).

I find it's an optimization feature that is a burden to the programmer,
and that can lead to new bugs due to opening extra UB possibilities.
But I'd be curious to see benchmarks that demonstrate the practical
performance gain that may be achieved. Perhaps it's worth it in some
limited, performance-critical parts of code.

> Number 4: variadic macros.

In over 20 years of C I think that I used a variadic macro maybe two
times. :) And IIRC this was the reason I switched to C99 for these
projects, at least temporarily (because each time the macro was some
dirty hack that wasn't meant to stay in production code).

> Number 3: variably modified types. Variable length arrays are
> sometimes problematic because of the danger of stack overflow.
> But variably modified types, which are akin to VLAs but not the
> same, provide similar benefits without the associated risk of
> blowing the stack.

I know VLAs because I have been bitten by them in the past, but the
Variably Modified Types *without* the concept of VLAs is a new one to
me. Would you mind providing a short example where such VMT-without-VLA
is used meaningfully?

> Number 2: non-constant block-level initializers for structs and
> arrays. In C89/C90 initializers for structs and array must have
> constant values for each element, including variables that are
> function locals. In C99 this limitation is removed, avoiding the
> need to do element-by-element assignment for what is logically
> just an initialization.

Saves a memcpy() call (on paper, not in implementation)... ok, why not.

> Number 1: compound literals and designated initializers.

The idea here, as I understand it, is to pass structs or unions to
functions without having to declare them first. As such:

#include <stdio.h>

struct t { int x, y; };

static void poo(struct t p) {
printf("x = %d , y = %d\n", p.x, p.y);
}

int main(void) {
poo((struct t){0, 1});
return(0);
}

I wondered for a while what practical use I could have of it, and the
only place I was able to find quickly is for calling select() without
declaring a timeout struct first. But that would work only if I do not
need to read the struct back (and often I do, and yes I know it's a
despicable linuxism). You put it as #1 reason for C99, though, so I
imagine there must be some other hugely interesting uses that I don't
see right away. I will keep that in mind in my future code, looking for
occasions where it could be a win.

> One key difference is that when using standard C you know what
> you're getting. To say that another way, standard C can be
> counted on to be the same across different platforms. Conversely
> it is frustrating to take a program that compiles under gnu C
> on one platform but doesn't on a different platform.

I understand your point, really, but I consider this to be rather a
matter of aesthetics. Whether you have an ISO C program with
platform-dependent functions in a separate file or a gnu89 program, the
end result won't differ that much... In both cases you will have to
spend some time to port the thing if target platform changes.

To sum up - from the list you kindly provided there are some things that
are simply diagnostics, and these are available in compilers also in
C89. Other things are nice additions to C89 and that they are also
available in gnu89 (if one accepts using gnu89). One or two features
that are of disputable interest (because they depend on individual
needs probably), and then one or two that are potentially interesting. I
don't see any revolution that would change my coding life, but
nonetheless I will keep an eye on those one or two potentially
interesting things in the context of my daily work.

Mateusz

On 04/02/2022 15:53, Mateusz Viste wrote:
> 2022-02-04 at 15:27 +0100, David Brown wrote:
>> That is a completely separate issue, and nothing to do with the
>> question, which was "what advantages are there to using _Bool over an
>> plain integer type?".
>
> I think that in a vicious way, it is not separate.
>
>> Yes, it's hard to see what
>> SetSpnEdit(height_spn, height, true, false, false);
>>
>> is doing. But you don't make anything better by writing
>> SetSpnEdit(height_spn, height, 1, 0, 0);
>
> If I would be a user of _Bool, I'd be very tempted to use the first form
> (and end up with a hardly readable line).

I think you need to work on your temptation issues. When a language
supports a feature, you are not /required/ to use it just because it is
there. There are perhaps a dozen different ways to make the call to
SetSpnEdit clearer and safer - none of them are in any way broken by the
existence of "_Bool".

> I guess it's a vicious side effect of the human mind - "if I have a
> hammer, then everything looks like nails". :-)
>

You seem to be limiting yourself severely as a programmer. How you code
is of course up to you, but please do not assume all programmers are
going to see things that way.

And your analogy is all wrong. You are claiming that because you only
have a hammer (int), you are better equipped to invent a spanner when
you need it than people who also have access to a screwdriver (_Bool).

There is an argument to be made that the power of a programming language
comes from what it stops you from doing just as much as from what it
allows you to do, and that more features and possibilities allows for
more misuse as well as more good usage. I really don't think C99 comes
anywhere close to having too many features as a language. Historically,
many of the new features of C99 were taken from gcc (and other
compilers) extensions to C90 (such as "inline", C++ comments, and mixing
statements and declarations), or as standardisations of existing common
practices (such as size-specific integer types and boolean types). To a
fair extent, C99 was a standardisation of the language people were
already using for C programming.

On 04/02/2022 20:38, Bart wrote:
> On 04/02/2022 10:06, David Brown wrote:

>> Secondly, there are technical differences.  The conversion of an integer
>> "x" to a _Bool "b" is effectively "b = !!x;".  You are guaranteed that
>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>> optimisation (as can the programmer).  This can mean some operations
>> (such as conversion from an integer) may be less efficient, but other
>> operations (such as logical operations) are more efficient.  Overall, it
>> is usually a win.
>
> You're never really quite sure what's happening with _Bool.
>
> There's little control over its size. And in A program like this:
>
>     union {
>         _Bool a;
>         unsigned char b;
>     } x;
>
>     x.b=0x55;
>     printf("A= %X\n", x.a);
>     printf("B= %X\n", x.b);
>

<snip>

> You can probably claim this is due to UB or whatever, but the fact
> remains that using regular int types, the results will be consistent and
> predictable across all compilers. It /is/ possible for the byte value
> that usually represents a bool type to be set something that is neither
> true (1) or false (0).
>

It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
you care.) It is also common sense. A _Bool contains either 0 or 1 -
any other value is invalid and can't be achieved without extraordinary
effort designed purely to make bad code.

Yes, you know /exactly/ what is happening with _Bool - write sane code,
and you get the results you expect. Write code with clear and
intentional errors with the sole intention of getting inconsistent
results, and you get exactly what you expect.