On 12/02/2024 17:13, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 12/02/2024 12:38, bart wrote:
>>> On 12/02/2024 11:26, David Brown wrote:
>>>> On 12/02/2024 04:34, Keith Thompson wrote:
>>>>> Oh, and conversion from any scalar type to _Bool yields either (_Bool)0
>>>>> or (_Bool)1, a major difference between _Bool and all other scalar
>>>>> types.
>>>>
>>>> Absolutely.  There is a /massive/ difference between:
>>>>
>>>>      int * p;
>>> I assume the * is a typo?
>>
>> No.
>>
>>>
>>>>      _Bool b = p;
>>
>> This is equivalent to "b = (p != NULL);" and does not elicit a warning
>> from gcc (-Wall -Wextra -Wpedantic -std=C11).
>>
>> (You might feel that there /should/ be a warning about it - that's
>> another matter. I'm saying what gcc does here, not what I think it
>> should do.)
>>
>>>> and
>>>>
>>>>      int x = p;
>>>>
>>
>> This will set "x" to an integer value based on the pointer's
>> address. It is almost certainly not something the programmer wanted,
>> and elicits a warning from gcc even without any options.
>
> This is a constraint violation. A compiler that doesn't reject it
> *might* generate code that behaves as you suggest.
>

You are (unsurprisingly) correct. I was only paying attention to the
rules for the conversion itself.

On 12/02/2024 11:40, David Brown wrote:
> On 11/02/2024 19:00, Malcolm McLean wrote:
>>
> That is why C99 calls the type "_Bool", and you need to include
> <stdbool.h> to get the nicer name "bool".  Now with C23, the C standards
> committee feel confident that the proportion of code that used "bool"
> for their own types is small enough that it is safe to make "bool",
> "true" and "false" keywords.
>
> And it is why it is insane to suggest that it is a good idea to make
> your own pseudo-boolean type in C and call it "bool".  It was a
> questionable idea in the late nineties when C99 was known to be coming
> soon, a bad idea in the early naughties when it had been published and
> compiler support was gaining, and is certainly not an acceptable idea now.
>
>> A simple typedef bool "bool" to "int" and definiing "true" and "false"
>> creates problems because there are no namespaces, you export the
>> symbols, and either they clash or they create mismash of subtly
>> different Boolean types.
>
> Correct.
>
>> So I am not recommending it in user code.
>
> Then what were you doing when you wrote this?
>
> """
>     You can achieve most of the benefits of a boolean type by aliasing
>     "int' to "bool" and defining "true" and "false", and a lot of C
>     installations do exactly this.
> """
>
>> However I am saying that it does achieve most of the benefits of
>> having a boolean type, and therefore people who do this are not
>> entirely stupid. But I'm talking about the C installation, so normally
>> the person who provides the compiler, not the user code.
>>
>
> And what is a "C installation" ?  Do you mean a "C /implementation/" ?
> Do you mean your own modification to headers or libraries after you have
> installed a toolchain?  Do you mean a company's standard additional
> libraries?
>
> Or do you mean that C implementations simply put "typedef int bool;" as
> their <stdbool.h> implementation?  That would, of course, be utter
> nonsense.
>
>
The "C installation " is not a rigorously defined concept and can be
thought of as a fuzzy set. But basically it means someone who provides
both the compiler and a library which must be used on that platform, and
therefore has a similar status to the standard library, but just for
that platform.
So for example Mircrosoft provide a file called "windef.h" which
contains the following declarations.

typedef int BOOL;

#ifndef FALSE
#define FALSE 0
#endif

#ifndef TRUE
#define TRUE 1
#endif

They use upper case. But otherwise it's exactly as I stated. In my view
this is reasonable. But it wouldn't be reasonable in a libarary designed
to do fast Fiurier transforms, for example. It's reasonable because
windef.h is part of the "C installation".

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2/12/2024 3:49 AM, David Brown wrote:
> On 11/02/2024 22:15, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 11/02/2024 02:08, Ben Bacarisse wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Sat, 10 Feb 2024 16:58:01 +0100, David Brown wrote:
>>>>>> It says "Assignment operators shall not be used in expressions which
>>>>>> return Boolean values", at least in my copy of MISRA 1998.
>>>>>
>>>>> One thing with that wording, it would disallow chained assignments
>>>>> in such
>>>>> innocuous cases as
>>>>>
>>>>>       a = b = c == d;
>>>>>
>>>>> since, after all, the expression is returning a boolean.
>>>> The type of c == d is int, but the value will be either 0 or 1.  Is
>>>> that
>>>> what you mean by an expression "returning a boolean" -- an
>>>> expression of
>>>> type in with either 0 or 1 as the value?
>>>
>>> I think that is what MISRA means when they talk about "essentially
>>> boolean" - but as I mentioned before, they don't define the term at
>>> all.   (MISRA 2012 supports C99, and also appears to consider _Bool as
>>> "essentially boolean", despite not defining it.)
[...]

https://www.stroustrup.com/JSF-AV-rules.pdf

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/12/2024 3:49 AM, David Brown wrote:
>> On 11/02/2024 22:15, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 11/02/2024 02:08, Ben Bacarisse wrote:
>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>> On Sat, 10 Feb 2024 16:58:01 +0100, David Brown wrote:
>>>>>>> It says "Assignment operators shall not be used in expressions which
>>>>>>> return Boolean values", at least in my copy of MISRA 1998.
>>>>>>
>>>>>> One thing with that wording, it would disallow chained
>>>>>> assignments in such
>>>>>> innocuous cases as
>>>>>>
>>>>>>       a = b = c == d;
>>>>>>
>>>>>> since, after all, the expression is returning a boolean.
>>>>> The type of c == d is int, but the value will be either 0 or 1.  Is
>>>>> that
>>>>> what you mean by an expression "returning a boolean" -- an
>>>>> expression of
>>>>> type in with either 0 or 1 as the value?
>>>>
>>>> I think that is what MISRA means when they talk about "essentially
>>>> boolean" - but as I mentioned before, they don't define the term at
>>>> all.   (MISRA 2012 supports C99, and also appears to consider _Bool as
>>>> "essentially boolean", despite not defining it.)
> [...]
>
> https://www.stroustrup.com/JSF-AV-rules.pdf

Yes, and?

That's a 141-page PDF document with rules for C++. Did you want to say
something about it?

As it happens, it does contain a relevant rule that *could* be
applicable to C:
"""
AV Rule 204
A single operation with side-effects shall only be used in the
following contexts:
1. by itself
2. the right-hand side of an assignment
3. a condition
4. the only argument expression with a side-effect in a function call
5. condition of a loop
6. switch condition
7. single part of a chained operation.
"""
which is substantially more permissive than the MISRA rules.

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

On 12/02/2024 21:27, Malcolm McLean wrote:
> On 12/02/2024 11:40, David Brown wrote:
>> On 11/02/2024 19:00, Malcolm McLean wrote:
>>>
>> That is why C99 calls the type "_Bool", and you need to include
>> <stdbool.h> to get the nicer name "bool".  Now with C23, the C
>> standards committee feel confident that the proportion of code that
>> used "bool" for their own types is small enough that it is safe to
>> make "bool", "true" and "false" keywords.
>>
>> And it is why it is insane to suggest that it is a good idea to make
>> your own pseudo-boolean type in C and call it "bool".  It was a
>> questionable idea in the late nineties when C99 was known to be coming
>> soon, a bad idea in the early naughties when it had been published and
>> compiler support was gaining, and is certainly not an acceptable idea
>> now.
>>
>>> A simple typedef bool "bool" to "int" and definiing "true" and
>>> "false" creates problems because there are no namespaces, you export
>>> the symbols, and either they clash or they create mismash of subtly
>>> different Boolean types.
>>
>> Correct.
>>
>>> So I am not recommending it in user code.
>>
>> Then what were you doing when you wrote this?
>>
>> """
>>      You can achieve most of the benefits of a boolean type by aliasing
>>      "int' to "bool" and defining "true" and "false", and a lot of C
>>      installations do exactly this.
>> """
>>
>>> However I am saying that it does achieve most of the benefits of
>>> having a boolean type, and therefore people who do this are not
>>> entirely stupid. But I'm talking about the C installation, so
>>> normally the person who provides the compiler, not the user code.
>>>
>>
>> And what is a "C installation" ?  Do you mean a "C /implementation/" ?
>> Do you mean your own modification to headers or libraries after you
>> have installed a toolchain?  Do you mean a company's standard
>> additional libraries?
>>
>> Or do you mean that C implementations simply put "typedef int bool;"
>> as their <stdbool.h> implementation?  That would, of course, be utter
>> nonsense.
>>
>>
> The "C installation " is not a rigorously defined concept and can be
> thought of as a fuzzy set. But basically it means someone who provides
> both the compiler and a library which must be used on that platform, and
> therefore has a similar status to the standard library, but just for
> that platform.

That would be the "C implementation", and it /is/ a well-established
term. It would be helpful if you used the standard terms here.

> So for example Mircrosoft provide a file called "windef.h" which
> contains the following declarations.
>
> typedef int                 BOOL;
>
> #ifndef FALSE
> #define FALSE               0
> #endif
>
> #ifndef TRUE
> #define TRUE                1
> #endif
>

None of that defines "bool", "true" or "false". This is /very/ different.

It is a typical pre-C99 pseudo-boolean, and made sense before C99. The
"windef.h" file needs to keep these for compatibility, especially in
light of MS's notoriously poor and late C99 support, but no one should
consider using them for anything now except as required for
compatibility with external code that has them. (For example, if you
are calling a function that takes a "BOOL *" pointer, you can't replace
that with a "bool *" pointer.)

> They use upper case. But otherwise it's exactly as I stated.

And the upper case makes all the difference. As far as C is concerned,
and as far as any trained C programmer is concerned, the difference is
perfectly clear. Windows has a convention in its API and windef.h and
windows.h headers of using all-caps names for locally defined type names
that are specific and consistent for all Windows versions, and don't
change according to the processor type - things like BYTE and LONG have
existed from 16-bit Windows, through 32-bit and 64-bit Windows. They
are not easily mistaken for the C standard types.

> In my view
> this is reasonable. But it wouldn't be reasonable in a libarary designed
> to do fast Fiurier transforms, for example. It's reasonable because
> windef.h is part of the "C installation".
>

I agree that this was a reasonable practice from MS, prior to C99. I
wish they had moved over to C99 types like "bool" and the sized integer
types (int32_t, etc.) as soon as these were standardised, keeping the
old all-caps types only for compatibility with old code, and deprecating
them as soon as reasonably possible. But prior to C99 they couldn't
really have done much better. And I agree that a major C
implementation, and the nearest Windows has to standard platform
headers, can reasonably claim generic names like BOOL.

It is normal for C90 libraries to have their own types for things like
booleans, but they should be named with prefixes like the rest of the
library - so you might have "fft_Boolean". Of course, anything this
century should be in at least C99 and use standard types, but this kind
of thing still hangs around because some code stretches back to last
century.

But these types are /not/ a substitute for standard C bool. They don't
do the same thing. They are not as good. They are not as standard.
They were the best be had a generation ago, but there is no reason to
use them now except for interfacing with old code, and certainly no
reason to consider defining a new home-made boolean.

On 13/02/2024 08:07, David Brown wrote:
> On 12/02/2024 21:27, Malcolm McLean wrote:
>>
>> The "C installation " is not a rigorously defined concept and can be
>> thought of as a fuzzy set. But basically it means someone who provides
>> both the compiler and a library which must be used on that platform,
>> and therefore has a similar status to the standard library, but just
>> for that platform.
>
> That would be the "C implementation", and it /is/ a well-established
> term.  It would be helpful if you used the standard terms here.
>

The "C implentation" would be be the program created by the person who
writes the complier. The "C installation" the system set up by the
person who provides the compiler. Often one and the same, but not
necessarily. You can have a compiler written by someone else and an API
written by someone else, put them together, and say "this shall be what
we use to create C programs for this platform". So you have set up the C
installation, but you are not the implementor.

>> So for example Mircrosoft provide a file called "windef.h" which
>> contains the following declarations.
>>
>> typedef int                 BOOL;
>>
>> #ifndef FALSE
>> #define FALSE               0
>> #endif
>>
>> #ifndef TRUE
>> #define TRUE                1
>> #endif
>>
>
> None of that defines "bool", "true" or "false".  This is /very/ different.
>
> It is a typical pre-C99 pseudo-boolean, and made sense before C99.  The
> "windef.h" file needs to keep these for compatibility, especially in
> light of MS's notoriously poor and late C99 support, but no one should
> consider using them for anything now except as required for
> compatibility with external code that has them.  (For example, if you
> are calling a function that takes a "BOOL *" pointer, you can't replace
> that with a "bool *" pointer.)
>
>> They use upper case. But otherwise it's exactly as I stated.
>
> And the upper case makes all the difference.  As far as C is concerned,
> and as far as any trained C programmer is concerned, the difference is
> perfectly clear.  Windows has a convention in its API and windef.h and
> windows.h headers of using all-caps names for locally defined type names
> that are specific and consistent for all Windows versions, and don't
> change according to the processor type - things like BYTE and LONG have
> existed from 16-bit Windows, through 32-bit and 64-bit Windows.  They
> are not easily mistaken for the C standard types.
>
>> In my view this is reasonable. But it wouldn't be reasonable in a
>> libarary designed to do fast Fiurier transforms, for example. It's
>> reasonable because windef.h is part of the "C installation".
>>
>
> I agree that this was a reasonable practice from MS, prior to C99.  I
> wish they had moved over to C99 types like "bool" and the sized integer
> types (int32_t, etc.) as soon as these were standardised, keeping the
> old all-caps types only for compatibility with old code, and deprecating
> them as soon as reasonably possible.  But prior to C99 they couldn't
> really have done much better.  And I agree that a major C
> implementation, and the nearest Windows has to standard platform
> headers, can reasonably claim generic names like BOOL.
>
> It is normal for C90 libraries to have their own types for things like
> booleans, but they should be named with prefixes like the rest of the
> library - so you might have "fft_Boolean".  Of course, anything this
> century should be in at least C99 and use standard types, but this kind
> of thing still hangs around because some code stretches back to last
> century.
>
Yes, and it's a nightmare, because whilst it's obvious that an
fft_boolean is a variable which is meant to represent "true" or "false",
it's not so obvious where code which calls but does not implement the
Fourier transforms should use it, and it might not even be binary
compatible with other types in the program designed to do the same
thing. A standrd atype is blessing, and all you really need for that is
a simple standard header declaring "bool" as a type, and "true" and
"false" as constants. Now "false" must be zero, But should "true" be 1
or -1?
>
> But these types are /not/ a substitute for standard C bool.  They don't
> do the same thing.  They are not as good.  They are not as standard.
> They were the best be had a generation ago, but there is no reason to
> use them now except for interfacing with old code, and certainly no
> reason to consider defining a new home-made boolean.
>
I discussed using Pico C to implement a build system recently. Now I
have't checked, but it's not fully featured and I don't think it
supports coercing a boolean to be 1 or 0. But by providing a trivial
header we could get most C source which uses "bool" to interpret
correctly. And that would be a lot easier than trying to modify the
interpeter. Of course

char *ptr = something();
bool flag = (bool) ptr;
if (flag == true)

will not be interpreted correctly. But we can live with that.

The Pico C would be our "C installation" by the way. We wouldn't claim
to be the implenters. Not every word has to have been used before in
exactly the same context to be used correctly, as you seem to think.

(Now let's start a flame war because I did English at Oxford whilst you
didn't).
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 13/02/2024 10:35, Malcolm McLean wrote:
> On 13/02/2024 08:07, David Brown wrote:
>> On 12/02/2024 21:27, Malcolm McLean wrote:
>>>
>>> The "C installation " is not a rigorously defined concept and can be
>>> thought of as a fuzzy set. But basically it means someone who
>>> provides both the compiler and a library which must be used on that
>>> platform, and therefore has a similar status to the standard library,
>>> but just for that platform.
>>
>> That would be the "C implementation", and it /is/ a well-established
>> term.  It would be helpful if you used the standard terms here.
>>
>
> The "C implentation" would be be the program created by the person who
> writes the complier.

No, that would be the compiler.

The "C implementation" includes the compiler, associated tools like
assemblers and linkers, headers, the standard C library, and parts of
the target system that are needed in order to execute the program.

> The "C installation" the system set up by the
> person who provides the compiler.

I am trying to understand what you mean by this - as usual, it is not
easy as you insist on using your own invented terms in your own way, and
have great difficultly explaining them to others.

Maybe you are talking about what others might refer to as a "toolchain",
which typically includes the non-compiler parts of the C implementation
(like an assembler, linker, and standard library), as well as additional
useful tools such as objcopy, make, a debugger, and perhaps an editor or
IDE, and common platform-specific headers and libraries. MSVC is a
toolchain, and comes with windef.h (amongst many other things). You
might also refer to TDM as a Windows-hosted gcc toolchain.

But you might also be talking about a customised setup, either done by
an individual on their own systems, or by a company wanting all their
developers to have the same development environment.

> Often one and the same, but not
> necessarily. You can have a compiler written by someone else and an API
> written by someone else, put them together, and say "this shall be what
> we use to create C programs for this platform". So you have set up the C
> installation, but you are not the implementor.
>

The term "C implementation" is not connected to who makes the compiler,
library, installation packages or anything else. It's a /thing/, not a
person or group, and it is the characteristics of the C implementation
that are important, not where it came from.

>>> So for example Mircrosoft provide a file called "windef.h" which
>>> contains the following declarations.
>>>
>>> typedef int                 BOOL;
>>>
>>> #ifndef FALSE
>>> #define FALSE               0
>>> #endif
>>>
>>> #ifndef TRUE
>>> #define TRUE                1
>>> #endif
>>>
>>
>> None of that defines "bool", "true" or "false".  This is /very/
>> different.
>>
>> It is a typical pre-C99 pseudo-boolean, and made sense before C99.
>> The "windef.h" file needs to keep these for compatibility, especially
>> in light of MS's notoriously poor and late C99 support, but no one
>> should consider using them for anything now except as required for
>> compatibility with external code that has them.  (For example, if you
>> are calling a function that takes a "BOOL *" pointer, you can't
>> replace that with a "bool *" pointer.)
>>
>>> They use upper case. But otherwise it's exactly as I stated.
>>
>> And the upper case makes all the difference.  As far as C is
>> concerned, and as far as any trained C programmer is concerned, the
>> difference is perfectly clear.  Windows has a convention in its API
>> and windef.h and windows.h headers of using all-caps names for locally
>> defined type names that are specific and consistent for all Windows
>> versions, and don't change according to the processor type - things
>> like BYTE and LONG have existed from 16-bit Windows, through 32-bit
>> and 64-bit Windows.  They are not easily mistaken for the C standard
>> types.
>>
>>> In my view this is reasonable. But it wouldn't be reasonable in a
>>> libarary designed to do fast Fiurier transforms, for example. It's
>>> reasonable because windef.h is part of the "C installation".
>>>
>>
>> I agree that this was a reasonable practice from MS, prior to C99.  I
>> wish they had moved over to C99 types like "bool" and the sized
>> integer types (int32_t, etc.) as soon as these were standardised,
>> keeping the old all-caps types only for compatibility with old code,
>> and deprecating them as soon as reasonably possible.  But prior to C99
>> they couldn't really have done much better.  And I agree that a major
>> C implementation, and the nearest Windows has to standard platform
>> headers, can reasonably claim generic names like BOOL.
>>
>> It is normal for C90 libraries to have their own types for things like
>> booleans, but they should be named with prefixes like the rest of the
>> library - so you might have "fft_Boolean".  Of course, anything this
>> century should be in at least C99 and use standard types, but this
>> kind of thing still hangs around because some code stretches back to
>> last century.
>>
> Yes, and it's a nightmare, because whilst it's obvious that an
> fft_boolean is a variable which is meant to represent "true" or "false",
> it's not so obvious where code which calls but does not implement the
> Fourier transforms should use it, and it might not even be binary
> compatible with other types in the program designed to do the same
> thing. A standrd atype is blessing, and all you really need for that is
> a simple standard header declaring "bool" as a type, and "true" and
> "false" as constants. Now "false" must be zero, But should "true" be 1
> or -1?

Have you been living under a rock for the last 25 years? Do you write
code for the OCCC, or are you aiming for a "featured article" in the
Daily WTF?

<https://thedailywtf.com/articles/what_is_truth_0x3f_>
<https://thedailywtf.com/articles/Extra-Boolean>

Yes, a standard boolean type is an extremely important feature in a
programming language. The fact that C did not have one until C99 has
resulted in a great deal of inconvenience and wasted effort. Then in
1999, we got a standard boolean type in C. Use it! No, it is not
sufficient to have a "typedef int bool" in a header to make a /good/
boolean type. No, "true" should not be -1. No, you should never define
your own type "bool".

> >
>> But these types are /not/ a substitute for standard C bool.  They
>> don't do the same thing.  They are not as good.  They are not as
>> standard. They were the best be had a generation ago, but there is no
>> reason to use them now except for interfacing with old code, and
>> certainly no reason to consider defining a new home-made boolean.
>>
> I discussed using Pico C to implement a build system recently. Now I
> have't checked, but it's not fully featured and I don't think it
> supports coercing a boolean to be 1 or 0. But by providing a trivial
> header we could get most C source which uses "bool" to interpret
> correctly. And that would be a lot easier than trying to modify the
> interpeter. Of course
>
> char *ptr = something();
> bool flag = (bool) ptr;
> if (flag == true)
>
> will not be interpreted correctly. But we can live with that.

We can live with all kinds of things - that does not mean we /should/
live with it.

Pico C appears to be a dead project. And it was never intended to be
more than a tiny handler for a subset of C - of unspecified version, and
without any attempt at conformance. It's broken version of <stdbool.h>
is dangerously wrong and has no place in anything that claims to call
itself "C" or "C-like". It should be either fixed, or removed entirely.
But as it is a dead project there is little point in reporting the error.

>
> The Pico C would be our "C installation" by the way.

Or, to use the correct term, the "C implementation". Or perhaps the
"Sort-of C implementation".

> We wouldn't claim
> to be the implenters. Not every word has to have been used before in
> exactly the same context to be used correctly, as you seem to think.
>

On 13/02/2024 10:36, David Brown wrote:
> On 13/02/2024 10:35, Malcolm McLean wrote:
>>
> I am trying to understand what you mean by this - as usual, it is not
> easy as you insist on using your own invented terms in your own way, and
> have great difficultly explaining them to others.
>
Its' quite simple. Basically in my view you have no business declaring
and exporting a boolean type if you are an ordinary library writer. Only
if you set things up. Only if you are Microsoft or Nintendo or someone
else who legitimately may claim to have the right to dictate what should
and should not be on that platform. Which normally means that you will
alos be the person who writes the compiler and therefore the
"implementor". But not necessarily, so "implentation" ins;t quite th
right word and we need anew one. I don't think there is a generally
accepted term for this idea, as is often the case for unexceptional and
rutine ideas which neverthelss don;t come up very often. So I chose
"installation", a perfectly normal word which in slang means "the set up".

Now this sort of thing irritates some of the others, and so I shouldn't
have to explain and justify to some people the basics of how to use the
English language.

> Maybe you are talking about what others might refer to as a "toolchain",
> which typically includes the non-compiler parts of the C implementation
> (like an assembler, linker, and standard library), as well as additional
> useful tools such as objcopy, make, a debugger, and perhaps an editor or
> IDE, and common platform-specific headers and libraries.  MSVC is a
> toolchain, and comes with windef.h (amongst many other things).  You
> might also refer to TDM as a Windows-hosted gcc toolchain.
>
> But you might also be talking about a customised setup, either done by
> an individual on their own systems, or by a company wanting all their
> developers to have the same development environment.
>
Yes, can be the second. Embedded developers talk about "toolchains" but
non-embedded developers mostly don't, and it's not really relevant that
in a typical C implemntation several programs are run to create the
exectuable instead of only one. But it is relevant that all the
developers have the same development environment. If everyone shall use
"BOOL" rather than "bool" because that is the customised common header
chosen by the company, that's exactly what I am talking about.
>
>> Yes, and it's a nightmare, because whilst it's obvious that an
>> fft_boolean is a variable which is meant to represent "true" or
>> "false", it's not so obvious where code which calls but does not
>> implement the Fourier transforms should use it, and it might not even
>> be binary compatible with other types in the program designed to do
>> the same thing. A standrd atype is blessing, and all you really need
>> for that is a simple standard header declaring "bool" as a type, and
>> "true" and "false" as constants. Now "false" must be zero, But should
>> "true" be 1 or -1?
>
> Have you been living under a rock for the last 25 years?  Do you write
> code for the OCCC, or are you aiming for a "featured article" in the
> Daily WTF?
>
> <https://thedailywtf.com/articles/what_is_truth_0x3f_>
> <https://thedailywtf.com/articles/Extra-Boolean>
>
"Have you stopped beating your wife?"
True / false often isn't adequate. And fuzzy logic is an attempt to
address this sort of issue. Another way would be to add extra
categories, like "unknown", "halfway between", or, in this case "unfair".

> Yes, a standard boolean type is an extremely important feature in a
> programming language.  The fact that C did not have one until C99 has
> resulted in a great deal of inconvenience and wasted effort.  Then in
> 1999, we got a standard boolean type in C.  Use it!  No, it is not
> sufficient to have a "typedef int bool" in a header to make a /good/
> boolean type.  No, "true" should not be -1.  No, you should never define
> your own type "bool".
>
true can be -1 in boolean logic. The real reason is that -1 is all bits
set, so ~true == false. But of course a one bit number is either -1 or 0
in two;s complement notation.
However someone has to take decsion on this and there should be one
standard, I totally agree.
>
> Pico C appears to be a dead project.  And it was never intended to be
> more than a tiny handler for a subset of C - of unspecified version, and
> without any attempt at conformance.  It's broken version of <stdbool.h>
> is dangerously wrong and has no place in anything that claims to call
> itself "C" or "C-like".  It should be either fixed, or removed entirely.
>  But as it is a dead project there is little point in reporting the error.
>
There aren't that many open source, free to use C intepreters hanging
around. I did try to use Pico C for a hobby project that never got to
release, and one of the reasons I abandoned it was that Pico C was
difficult to use. But I did get C functions entered and running. If
"bool" is available then it makes programs a bit easier to read and
there is a slight benefit, but it's only slight, and you can write C
programs perfectly well without it. The problem comes when people who
have no business doing so declare a boolean type. If Pico C calls its
boolean header stdbool.h and it is subtly different from how stdbool.h
is supposed to work then it could be dangerous, I agree, but it's
unlikely anyone would connect my hobby project up to a nuclear missile.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 13/02/2024 10:36, David Brown wrote:
> On 13/02/2024 10:35, Malcolm McLean wrote:
>> On 13/02/2024 08:07, David Brown wrote:

>> The "C implentation" would be be the program created by the person who
>> writes the complier.
>
> No, that would be the compiler.
>
> The "C implementation" includes the compiler, associated tools like
> assemblers and linkers, headers, the standard C library, and parts of
> the target system that are needed in order to execute the program.
>
>> The "C installation" the system set up by the person who provides the
>> compiler.
>
> I am trying to understand what you mean by this - as usual, it is not
> easy as you insist on using your own invented terms in your own way, and
> have great difficultly explaining them to others.
>
> Maybe you are talking about what others might refer to as a "toolchain",

It seems clear to me what the difference is between installation and
implementation.

A factory implements a washing machine, and somebody else decides where
to install it in their house and how and to what it is hooked up.

There might be have two or more installations.

My original C compiler had one of the simplest possible installations:
just run the EXE from wherever it happens to be. Yet even there, you
need to know /where/ it is installed, even if it's just to add that
location to a set of search paths.

Installing two gcc versions on Windows is problematical because gcc
invokes other binaries. Because rather than using paths relative to the
gcc.exe that was run, it uses system PATH settings, so that when it
invokes ld.exe for example, it may end up with ld.exe belonging to the
other installation.

This is little to do with implementation (other than the implementation
is buggy IMO).

>> Often one and the same, but not necessarily. You can have a compiler
>> written by someone else and an API written by someone else, put them
>> together, and say "this shall be what we use to create C programs for
>> this platform". So you have set up the C installation, but you are not
>> the implementor.
>>
>
> The term "C implementation" is not connected to who makes the compiler,
> library, installation packages or anything else.  It's a /thing/, not a
> person or group, and it is the characteristics of the C implementation
> that are important, not where it came from.

So it just 'exists' without anyone having created it?

> Yes, a standard boolean type is an extremely important feature in a
> programming language.  The fact that C did not have one until C99 has
> resulted in a great deal of inconvenience and wasted effort.  Then in
> 1999, we got a standard boolean type in C.  Use it!  No, it is not
> sufficient to have a "typedef int bool" in a header to make a /good/
> boolean type.  No, "true" should not be -1.  No, you should never define
> your own type "bool".

It's not /that/ important. The concept is more important than having a
dedicated type.

I added a proper boolean type to my scripting language at one point.
Then I streamlined it and got rid of it.

There is an `integer` type which can represent a million different kinds
of things; why make a special type for a thing that has the values of 0
or 1?

(In dynamic code, extra types mean spending longer doing runtime type
checking.)

A proper _Bool type gives the possibility of arrays of _Bools that
occupy one bit per element. However that doesn't happen here:

_Bool A[1024];
printf("%zu\n", sizeof(A));

I get '1024' with gcc -O3, not 128. (My scripting language, despite not
having Bool, does have 1-bit arrays. Those can be more useful.)

>> will not be interpreted correctly. But we can live with that.
>
> We can live with all kinds of things - that does not mean we /should/
> live with it.
>
> Pico C appears to be a dead project.  And it was never intended to be
> more than a tiny handler for a subset of C - of unspecified version, and
> without any attempt at conformance.  It's broken version of <stdbool.h>
> is dangerously wrong and has no place in anything that claims to call
> itself "C" or "C-like".  It should be either fixed, or removed entirely.

You're fond of saying that.

>  But as it is a dead project there is little point in reporting the error.
>
>
>>
>> The Pico C would be our "C installation" by the way.
>
> Or, to use the correct term, the "C implementation".  Or perhaps the
> "Sort-of C implementation".

Even C++ is a 'sort-of-C' implementation.

Suppose you have a C program that uses 85% of the features of C. You use
a C compiler which only implements that same 85% subset. Your program
works perfectly.

But I guess you would still look down your knows at such a product?

Some C compilers implement a subset of the language, some a superset. I
expect a superset is fine? But neither are actually C!

And of course, using compiler options to further customise the language
is also acceptable.

"PicoC is a very small C interpreter for scripting. It was originally
written as the script language for a UAV's on-board flight system. It's
also very suitable for other robotic, embedded and non-embedded
applications."

Do you object to its use of "C"?

On 13/02/2024 13:12, Malcolm McLean wrote:
> On 13/02/2024 10:36, David Brown wrote:
>> On 13/02/2024 10:35, Malcolm McLean wrote:
>>>
>> I am trying to understand what you mean by this - as usual, it is not
>> easy as you insist on using your own invented terms in your own way,
>> and have great difficultly explaining them to others.
>>
> Now this sort of thing irritates some of the others, and so I shouldn't
> have to explain and justify to some people the basics of how to use the
> English language.

The way to avoid this would be to use standard terms correctly in the
first place. And if what you intend to say is not covered by the
standard term, explain what you mean - don't just leap in with yet
another home-made term and expect everyone else to read your mind.

>>
>> But you might also be talking about a customised setup, either done by
>> an individual on their own systems, or by a company wanting all their
>> developers to have the same development environment.
>>
> Yes, can be the second. Embedded developers talk about "toolchains" but
> non-embedded developers mostly don't, and it's not really relevant that
> in a typical C implemntation several programs are run to create the
> exectuable instead of only one. But it is relevant that all the
> developers have the same development environment. If everyone shall use
> "BOOL" rather than "bool" because that is the customised common header
> chosen by the company, that's exactly what I am talking about.

Finally we are getting somewhere.

>>
>>> Yes, and it's a nightmare, because whilst it's obvious that an
>>> fft_boolean is a variable which is meant to represent "true" or
>>> "false", it's not so obvious where code which calls but does not
>>> implement the Fourier transforms should use it, and it might not even
>>> be binary compatible with other types in the program designed to do
>>> the same thing. A standrd atype is blessing, and all you really need
>>> for that is a simple standard header declaring "bool" as a type, and
>>> "true" and "false" as constants. Now "false" must be zero, But should
>>> "true" be 1 or -1?
>>
>> Have you been living under a rock for the last 25 years?  Do you write
>> code for the OCCC, or are you aiming for a "featured article" in the
>> Daily WTF?
>>
>> <https://thedailywtf.com/articles/what_is_truth_0x3f_>
>> <https://thedailywtf.com/articles/Extra-Boolean>
>>
> "Have you stopped beating your wife?"
> True / false often isn't adequate.

I did not expect a yes/no answer to these rhetorical questions, and did
not in any way suggest that I was looking for one.

I was ridiculing the idea of making more home-made booleans 25 years
after they became unnecessary and outdated, and especially the idea of
doing something as silly as making "true" have the value -1.

>
>
>> Yes, a standard boolean type is an extremely important feature in a
>> programming language.  The fact that C did not have one until C99 has
>> resulted in a great deal of inconvenience and wasted effort.  Then in
>> 1999, we got a standard boolean type in C.  Use it!  No, it is not
>> sufficient to have a "typedef int bool" in a header to make a /good/
>> boolean type.  No, "true" should not be -1.  No, you should never
>> define your own type "bool".
>>
> true can be -1 in boolean logic.

No, it cannot. Boolean logic has "true" and "false", sometimes donated
1 and 0 for convenience. As a logic system, these 1 and 0
representations bear no relation to the normal numbers 1 and 0 - they
are just symbols.

Programming language implementations always need to represent things as
numbers in the end, since that is what computer hardware deals with.
How the logical concepts of "true" and "false" are represented is
arbitrary, though usually picked to be efficient to implement and
helpful to programmers if the language supports conversion from boolean
types to number types. Some languages use -1 for "true" in this sense,
others treat all non-zero values as "true". It is most common, I
believe, to see 1 as the canonical representation of "true". Some,
however, will use 0 for "true" and 1 for "false", or 'T' for true and
'F' for false, or other values.

The relevant language here is C. And C99 _Bool uses 1 for true. In all
versions of C, the relational operators and logical operators yield 1
for true, and 0 for false. Picking a value for a constant called "true"
such that "(true == true) != true" is considered "true" by the language
would be insane.

> The real reason is that -1 is all bits
> set, so ~true == false. But of course a one bit number is either -1 or 0
> in two;s complement notation.
> However someone has to take decsion on this and there should be one
> standard, I totally agree.

That decision was taken 50+ years ago when C was conceived.

>>
>> Pico C appears to be a dead project.  And it was never intended to be
>> more than a tiny handler for a subset of C - of unspecified version,
>> and without any attempt at conformance.  It's broken version of
>> <stdbool.h> is dangerously wrong and has no place in anything that
>> claims to call itself "C" or "C-like".  It should be either fixed, or
>> removed entirely.   But as it is a dead project there is little point
>> in reporting the error.
>>
> There aren't that many open source, free to use C intepreters hanging
> around.

That does not make Pico C any less of a dead project, or mean that it
handles anything other than a vaguely defined language based on a subset
of some unspecified version of C with dangerous (or at least unhelpful)
additions that differ pointlessly from standard C.

It might still be a useful tool. Just don't treat it as anything it is
not, and do not use it as some kind of justification for
misunderstanding "bool" in C.

bart <bc@freeuk.com> writes:

> On 13/02/2024 10:36, David Brown wrote:
>> On 13/02/2024 10:35, Malcolm McLean wrote:
>>> On 13/02/2024 08:07, David Brown wrote:
>
>>> The "C implentation" would be be the program created by the person who
>>> writes the complier.
>> No, that would be the compiler.
>> The "C implementation" includes the compiler, associated tools like
>> assemblers and linkers, headers, the standard C library, and parts of the
>> target system that are needed in order to execute the program.
>>
>>> The "C installation" the system set up by the person who provides the
>>> compiler.
>> I am trying to understand what you mean by this - as usual, it is not
>> easy as you insist on using your own invented terms in your own way, and
>> have great difficultly explaining them to others.
>> Maybe you are talking about what others might refer to as a "toolchain",
>
> It seems clear to me what the difference is between installation and
> implementation.

And yet I don't think you have understood what Malcolm means.

> A factory implements a washing machine, and somebody else decides where to
> install it in their house and how and to what it is hooked up.

But that can be you or I, and Malcolm has at last explained that the key
point (at least for him) is one of authority: the "installer" has the
authority (or maybe just the commercial clout) to insist on "the
installation" having a Boolean type, maybe even a non-standard one.

The person who "sets things up" (the "installer" of the "installation")
in Malcolm's world is Microsoft or Nintendo, not the person who
typically installs software on a single user machine. It could (I am
sure) be your employer, as they have the authority to insist you use
some specific Boolean type, so it is certainly not the same as a "C
implantation" in the sense used by the C standard.

Comp.lang.c has become so polarised that I can see how you want to be "on
Malcolm's side" here, but until just now he had not explained how he was
using the vague term "C installation". It's fine to avoid jargon, but
you do then have to explain what you mean, and it's still not 100% clear.

Ironically, an authority, the WG14 committee, has indeed decreed that "C
installations" should have a Boolean type spelled "bool" with "true" and
"false" as keywords.

It would have been so much simpler had he said, right off the bat, that
some entities (Microsoft, the WG14 committee, your employer) have the
clout to get away with insisting on a Boolean type, but library authors
do not. We could disagree with that, but at least we'd all be on the
same page to start with.

--
Ben.

On 13/02/2024 13:32, bart wrote:
> On 13/02/2024 10:36, David Brown wrote:
>> On 13/02/2024 10:35, Malcolm McLean wrote:
>>> On 13/02/2024 08:07, David Brown wrote:
>
>>> The "C implentation" would be be the program created by the person
>>> who writes the complier.
>>
>> No, that would be the compiler.
>>
>> The "C implementation" includes the compiler, associated tools like
>> assemblers and linkers, headers, the standard C library, and parts of
>> the target system that are needed in order to execute the program.
>>
>>> The "C installation" the system set up by the person who provides the
>>> compiler.
>>
>> I am trying to understand what you mean by this - as usual, it is not
>> easy as you insist on using your own invented terms in your own way,
>> and have great difficultly explaining them to others.
>>
>> Maybe you are talking about what others might refer to as a "toolchain",
>
>
> It seems clear to me what the difference is between installation and
> implementation.
>
> A factory implements a washing machine, and somebody else decides where
> to install it in their house and how and to what it is hooked up.

I would agree with that difference (and the distinction you made below,
which I snipped for brevity).

But it is not, apparently, what Malcolm is talking about.

However, I am pretty sure that that discussion is going nowhere, and
Malcolm will continue in his Humpty-Dumpty quest to use words to mean
exactly what /he/ thinks they mean, rather than trying to communicate
sensibly with others. And I am also fairly sure that it doesn't affect
the issues with booleans.

>>> Often one and the same, but not necessarily. You can have a compiler
>>> written by someone else and an API written by someone else, put them
>>> together, and say "this shall be what we use to create C programs for
>>> this platform". So you have set up the C installation, but you are
>>> not the implementor.
>>>
>>
>> The term "C implementation" is not connected to who makes the
>> compiler, library, installation packages or anything else.  It's a
>> /thing/, not a person or group, and it is the characteristics of the C
>> implementation that are important, not where it came from.
>
> So it just 'exists' without anyone having created it?
>

No. But the creator is irrelevant. A car is a "car" because of how it
works and what you can do with it. It doesn't matter if you built it
yourself or bought one pre-built.

>
>> Yes, a standard boolean type is an extremely important feature in a
>> programming language.  The fact that C did not have one until C99 has
>> resulted in a great deal of inconvenience and wasted effort.  Then in
>> 1999, we got a standard boolean type in C.  Use it!  No, it is not
>> sufficient to have a "typedef int bool" in a header to make a /good/
>> boolean type.  No, "true" should not be -1.  No, you should never
>> define your own type "bool".
>
> It's not /that/ important. The concept is more important than having a
> dedicated type.

The concept is made a lot clearer by having a dedicated type.

>
> I added a proper boolean type to my scripting language at one point.
> Then I streamlined it and got rid of it.
>
> There is an `integer` type which can represent a million different kinds
> of things; why make a special type for a thing that has the values of 0
> or 1?

The special type should hold values of true and false - it is the
restriction of the values that makes it special, and makes it suitable
for the concept of a boolean truth value. The restriction of values is key.

>
> (In dynamic code, extra types mean spending longer doing runtime type
> checking.)
>
> A proper _Bool type gives the possibility of arrays of _Bools that
> occupy one bit per element. However that doesn't happen here:
>
>     _Bool A[1024];
>     printf("%zu\n", sizeof(A));
>
> I get '1024' with gcc -O3, not 128. (My scripting language, despite not
> having Bool, does have 1-bit arrays. Those can be more useful.)

C's concepts of objects and arrays disallow such compact arrays. This
is both a limitation and a feature. On the one hand, it means you can't
conveniently have space-saving bit/bool arrays. On the other hand, it
means that if "xs" is an array, you can always access different elements
independently, all objects have unique addresses (within their
lifetimes), underlying representations of objects can copied with
memcpy(), every object has a "sizeof" size in bytes, and so on. Compact
bit/bool arrays are a useful concept, but would not fit as normal arrays
in C.

>
>>> will not be interpreted correctly. But we can live with that.
>>
>> We can live with all kinds of things - that does not mean we /should/
>> live with it.
>>
>> Pico C appears to be a dead project.  And it was never intended to be
>> more than a tiny handler for a subset of C - of unspecified version,
>> and without any attempt at conformance.  It's broken version of
>> <stdbool.h> is dangerously wrong and has no place in anything that
>> claims to call itself "C" or "C-like".  It should be either fixed, or
>> removed entirely.
>
> You're fond of saying that.

I think it is important.

I'm fine with compilers (or other C tools) handling only a subset of C,
or only an older version of the language. I'm fine with them having
extensions. I'm fine with them being not quite perfect, or having some
limitations or missing elements. But there are three things I want
tools to do:

1. Document what version of the C standards they support, what
limitations or subsets it has, and what extensions it has. Document how
to enable or disable these.

2. Make it clear right at the start if it really is a "C" tool, able to
conform substantially to at least one C standard, or a "Sort-of C" tool
that has significant and intentional deviations.

3. Do not have features that are syntactically the same as features of
C, but do not conform semantically to C. If there are outstanding
reasons for this, then it must at least be clearly documented.

Pico C breaks point 3 here, and it does so for no good reason. It could
simply have omitted <stdbool.h> and been just as useful. There is no
situation in which it is a good idea to have a <stdbool.h> header
defining a "bool" type that does not conform to the C99 "_Bool" type.

I've seen other compilers break point 3 for at least somewhat good
reasons, such as microcontroller compilers that have 32-bit "double" types.

The problem with this is that existing correct code could appear to
compile cleanly, but not work as expected even if the code was fully
portable conforming C. That is never a good thing.

I am not saying that tools that break these rules are not useful - I am
simply saying that I want tools that do so to be clear about it and
document it.

>
>>   But as it is a dead project there is little point in reporting the
>> error.
>>
>>
>>>
>>> The Pico C would be our "C installation" by the way.
>>
>> Or, to use the correct term, the "C implementation".  Or perhaps the
>> "Sort-of C implementation".
>
> Even C++ is a 'sort-of-C' implementation.

You could certainly consider it as having a sort-of C subset, yes.

>
> Suppose you have a C program that uses 85% of the features of C. You use
> a C compiler which only implements that same 85% subset. Your program
> works perfectly.
>
> But I guess you would still look down your knows at such a product?
>

If it implements a useful 85% subset of C (of some standard), and
/documents/ its missing features, that's fine.

I am fine with an implementation that says it implements C99 except for
complex numbers, wide characters and VLAs. No problem.

I am not fine an implementation that says it implements C99, and
provides <complex.h> where functions like ccos() were implement as a
simple "return" assembly instruction.

Do you see the difference?

> Some C compilers implement a subset of the language, some a superset. I
> expect a superset is fine? But neither are actually C!
>

Supersets are also fine, as long as they don't conflict with conforming
C. (It's okay if there are documented ways to enable or disable them.
A compiler could have "asm" statements as an extension, but should have
a flag to disable this for code that uses "asm" as an identifier.) And
to be useful, they should be documented.

On 13/02/2024 14:10, David Brown wrote:
> On 13/02/2024 13:32, bart wrote:
>>
>>
>> "PicoC is a very small C interpreter for scripting. It was originally
>> written as the script language for a UAV's on-board flight system.
>> It's also very suitable for other robotic, embedded and non-embedded
>> applications."
>>
>> Do you object to its use of "C"?
>>
>
> I don't know if it is close enough to some version of C for it to be
> reasonable to call it a "C compiler" (or "C interpreter") without
> qualification.  I haven't looked at it in any kind of detail.  But I
> /do/ know it has a <stdbool.h> header that most certainly does not
> define a C "bool" type, and I see that as a problem.  In particular, it
> is a pointless problem - it serves no purpose, but could cause subtle
> problems when used with code that is correct and conforming C, tested
> and debugged with other implementations.
>
So this is how they do it.

/* string.h library for large systems - small embedded systems use
clibrary.c instead */
#include "../interpreter.h"

#ifndef BUILTIN_MINI_STDLIB

static int trueValue = 1;
static int falseValue = 0;

/* structure definitions */
const char StdboolDefs[] = "typedef int bool;";

/* creates various system-dependent definitions */
void StdboolSetupFunc(Picoc *pc)
{ /* defines */
VariableDefinePlatformVar(pc, NULL, "true", &pc->IntType, (union
AnyValue *)&trueValue, FALSE);
VariableDefinePlatformVar(pc, NULL, "false", &pc->IntType, (union
AnyValue *)&falseValue, FALSE);
VariableDefinePlatformVar(pc, NULL,
"__bool_true_false_are_defined", &pc->IntType, (union AnyValue
*)&trueValue, FALSE);
}

#endif /* !BUILTIN_MINI_STDLIB */

Whilst I have't actually checked, presumably the interpreter calls
StdBoolSetUpFunc() when it hits "#include <stdbool.h>", and that puts
variables called "true" and "false" which are ints into global scope,
plus another int (not a boolean ironically) to flag that the function
has been called. Somehow the typedef is picked up elsewhere.

> That does not mean that it is not a useful tool.  But it would, IMHO, be
> a /better/ tool if that header were simply omitted entirely.
>
>
Now this means that the vast majority of code which is sanely written
and uses "stdbool.h", but isn't written specifically for Pico C, will be
interpreted correctly. But an tiny amount may break. And if it is
running on a UAV which is armed with a nuclear missile, that may be a
bit alarming. But mostly it won't be, and it will be fine.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 09.02.2024 18:09, Keith Thompson wrote:
>
> I suggest that the bug of using "=" where "==" was intended occurs
> almost exclusively among inexperienced C programmers, particularly those
> who are inexperienced with programming in general.

This opinion doesn't reflect reality.

Or only if by "inexperienced C programmers" you mean folks that
just haven't learned the C language - and have nonetheless been
assigned C tasks? - but such folks are no "C programmers" in the
first place.

>
> It's a mistake that's made because the programmer assumes that "="
> is a comparison operator, as it is in mathematics and in some other
> programming languages.

A precondition to be a programmer is that they know the language
(or otherwise first learn it); they certainly don't "assume" what
the syntax and basic semantics is. If you let folks ignorant of C
program your task you have a lot more problems than the assignment
operator.

> It's an easy and understandable mistake
> to make, but any reasonably experienced C programmer will have
> internalized the fact that "=" means assignment, not comparison.
> To a newbie, `if (x = y)` *looks like* a comparison. To an
> experienced C programmer it doesn't.
>
> (It's possible I'm overgeneralizing. For example, a programmer who
> commonly switches between C and other languages might still mix up "="
> and "==" occasionally.)

Yes, this is the case. Another case is where people still have the
mathematical notation in mind and refusing (=don't get used to) the
fact that "Reality" is "C". And sometimes it's just a typo.

>
> If C had used ":=" for assignment and "=" for comparison (and "=="
> probably not used for anything), the problem would never have come up,
> because ":=" doesn't look like a comparison even to a newbie. But it's
> far too late to fix that in any language called "C".

Indeed.

Janis

On 09.02.2024 14:43, David Brown wrote:
> [...]
>
> There are plenty of coding standards which ban the use of the results of
> assignment expressions, and I think there is little doubt that stricter
> coding standards reduce at least some kinds of errors in code. But it
> would be impossible to isolate the effect of one particular rule.
>
> If someone knows about such studies, it would be great to hear about
> them - failing that, guesses and gut feelings based on personal
> experience is about as good as we can get.

In the contexts I was working I never experienced (own or others')
real problems with cascading assignments. The only problems arose
with the if-assignment cases; to detect these errors at that time
time was lost (unnecessarily). (A price we had to pay when using
C/C++.)

Janis

On 10.02.2024 16:53, David Brown wrote:
>
> In MISRA 1998, the explanation for that rule includes:
>
> """
> Strictly speaking, in C, there is no Boolean type, but there is a
> conceptual difference between expressions which return a numeric value
> and expressions which return a Boolean value.
>
> If assignments are required then they must be performed separately
> outside of any expressions which are effectively of Boolean type.
> """
>
> MISRA regularly uses its own terms that are different from the Standard
> C terms, which IMHO is needlessly confusing and inaccurate. Sometimes
> these terms are defined, sometimes not. "Boolean" and "Effectively
> Boolean value" are not defined anywhere in MISRA 1998.

I don't know MISRA, but to me the two terms are quite clear in this
context; they are referring to the differentiation in the preceding
paragraph.

Janis

> [...]

On 11.02.2024 18:05, David Brown wrote:
>
> Yes, we all know that. (Well, everyone who has learned a bit of C99
> knows that.) It's very difficult to change things in a language that
> has as much use as C - changing the type of the value of expressions
> like "x == y" would have been a breaking change. When C++ was forked
> from C, it was able to make such breaking changes - thus "x == y" gives
> a bool in C++. But for C, it was too late.

You are mistaken; C++ had no 'bool' type initially. It had been added
later.

Janis

On 12.02.2024 02:17, Lawrence D'Oliveiro wrote:
>
> You seem to be saying that something like
>
> bool a = b == c;
>
> should not be allowed.

I have the habit to write such specific expressions with parenthesis

a = (b == c);

for own convenience or better maintainability. (Just BTW.)

Janis

On 13.02.2024 00:33, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>> https://www.stroustrup.com/JSF-AV-rules.pdf
>
> Yes, and?

I suppose it meant to use coding standards to prevent the worst and
make programmers aware of potential issues and pitfalls.

>
> That's a 141-page PDF document with rules for C++. Did you want to say
> something about it?

My first thought was: "How long will project start be delayed until
every project member will have read (and understood) that document?"

We used in the past also standards; one 80 page document (don't recall
its name, but it was internationally well established in the 1990's),
and an own one of much smaller size.

Of course it depends on the language. Well designed better languages
might need less standards that languages with lots of pitfalls (and
options).

Janis

On Tue, 13 Feb 2024 16:55:32 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 11.02.2024 18:05, David Brown wrote:
> >
> > Yes, we all know that. (Well, everyone who has learned a bit of C99
> > knows that.) It's very difficult to change things in a language
> > that has as much use as C - changing the type of the value of
> > expressions like "x == y" would have been a breaking change. When
> > C++ was forked from C, it was able to make such breaking changes -
> > thus "x == y" gives a bool in C++. But for C, it was too late.
>
> You are mistaken; C++ had no 'bool' type initially. It had been added
> later.
>
> Janis
>

Pre-history vs history.
As far as I am concerned, 'initially' == it presents in in the first
edition of "The C++ Programming Language".

On 13/02/2024 16:55, Janis Papanagnou wrote:
> On 11.02.2024 18:05, David Brown wrote:
>>
>> Yes, we all know that. (Well, everyone who has learned a bit of C99
>> knows that.) It's very difficult to change things in a language that
>> has as much use as C - changing the type of the value of expressions
>> like "x == y" would have been a breaking change. When C++ was forked
>> from C, it was able to make such breaking changes - thus "x == y" gives
>> a bool in C++. But for C, it was too late.
>
> You are mistaken; C++ had no 'bool' type initially. It had been added
> later.
>

It was there from the first standard version of C++. At that point, it
was still possible to make breaking changes - such as changing the type
of the result of comparison operators. But you are correct that it did
not exist in early drafts of C++ prior to standardisation.

On 11.02.2024 13:57, David Brown wrote:
>
> [...] They had been trying to rule out "if (x = y)"
> and requiring it to be written "x = y; if (x != 0) ...".

One could of course also have written it as

if (x = y) // this is intentionally an assignment!

Sometimes a comment is better than asking to rewrite the code.

Janis

On Fri, 09 Feb 2024 09:09:41 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

>
> If C had used ":=" for assignment and "=" for comparison (and "=="
> probably not used for anything), the problem would never have come up,
> because ":=" doesn't look like a comparison even to a newbie. But
> it's far too late to fix that in any language called "C".
>

If DMR ever considered := for assignment then it probably lasted no
longer than it took him to pay attention that in order to type ':' on
the standard keyboard one has to press shift.
But I think that he didn't consider it at all, due to reasoning that in
most programs assignments are far more common than comparisons for
equality. So, given his attitude,it was obvious to him which one of
the two has to be single character and which one can afford longer
form.

> On 09/02/2024 16:43, bart wrote:
>> What I wouldn't care about banning however is this:
>>
>> a += b += c;
>>
>> Because it's just confusing. If you don't think so, consider a, b, c
>> all having different numerical types.

To *ban* something because it is confusing to you?
Thus adding inconsistencies to the language?

What is it that confuses you? - I am assuming you know the operator
precedence rules, and that x += y like x = y returns a value?

Does using parenthesis to sort things maybe help you?

Janis

On 13/02/2024 16:20, Malcolm McLean wrote:
> On 13/02/2024 14:10, David Brown wrote:
>> On 13/02/2024 13:32, bart wrote:
>>>
>>>
>>> "PicoC is a very small C interpreter for scripting. It was originally
>>> written as the script language for a UAV's on-board flight system.
>>> It's also very suitable for other robotic, embedded and non-embedded
>>> applications."
>>>
>>> Do you object to its use of "C"?
>>>
>>
>> I don't know if it is close enough to some version of C for it to be
>> reasonable to call it a "C compiler" (or "C interpreter") without
>> qualification.  I haven't looked at it in any kind of detail.  But I
>> /do/ know it has a <stdbool.h> header that most certainly does not
>> define a C "bool" type, and I see that as a problem.  In particular,
>> it is a pointless problem - it serves no purpose, but could cause
>> subtle problems when used with code that is correct and conforming C,
>> tested and debugged with other implementations.
>>
> So this is how they do it.

By "they", you mean "the Pico C source code" rather than any users of
Pico C, or anyone else.

>
> /* string.h library for large systems - small embedded systems use
> clibrary.c instead */
> #include "../interpreter.h"
>
> #ifndef BUILTIN_MINI_STDLIB
>
> static int trueValue = 1;
> static int falseValue = 0;
>
>
> /* structure definitions */
> const char StdboolDefs[] = "typedef int bool;";
>
> /* creates various system-dependent definitions */
> void StdboolSetupFunc(Picoc *pc)
> {
>     /* defines */
>     VariableDefinePlatformVar(pc, NULL, "true", &pc->IntType, (union
> AnyValue *)&trueValue, FALSE);
>     VariableDefinePlatformVar(pc, NULL, "false", &pc->IntType, (union
> AnyValue *)&falseValue, FALSE);
>     VariableDefinePlatformVar(pc, NULL,
> "__bool_true_false_are_defined", &pc->IntType, (union AnyValue
> *)&trueValue, FALSE);
> }
>
> #endif /* !BUILTIN_MINI_STDLIB */
>
> Whilst I have't actually checked, presumably the interpreter calls
> StdBoolSetUpFunc() when it hits "#include <stdbool.h>", and that puts
> variables called "true" and "false" which are ints into global scope,
> plus another int (not a boolean ironically) to flag that the function
> has been called. Somehow the typedef is picked up elsewhere.
>
>
>> That does not mean that it is not a useful tool.  But it would, IMHO,
>> be a /better/ tool if that header were simply omitted entirely.
>>
>>
> Now this means that the vast majority of code which is sanely written
> and uses "stdbool.h", but isn't written specifically for Pico C, will be
> interpreted correctly.

That is not true.

Code that relies on "bool" values being 0 or 1 is perfectly "sane", and
will not work with the broken "bool" in Pico C.

Code that uses "bool b = p;", where "p" is a pointer, is perfectly sane
and may not work if Pico C correctly complains about the constraint
error from "int b = p;".

It is true that a lot of code that uses "bool", "true" and "false" will
work in the face of "typedef int bool". It is also true that some will
not - and there was nothing wrong or insane about the code. Such code
may fail subtly with Pico C, and only in some circumstances. People
using it will have to check their code, and change anything of the form
"bool b = x;" into "bool b = !!x;" to be sure.

> But an tiny amount may break. And if it is
> running on a UAV which is armed with a nuclear missile, that may be a
> bit alarming. But mostly it won't be, and it will be fine.
>

I am not at ease with an attitude of "There's a completely unnecessary,
known and easily fixable mistake in this software, but hopefully you
won't be using the tool for anything too serious and won't have many
problems". That is simply not how a programmer should think.

This one case rules out Pico C for me. I can agree that most uses of
"bool" will be okay - but apparently the Pico C author couldn't care
less about such things, and has neither the knowledge nor interest in
finding out how C is defined, and the project has no reviewers, testers,
bug reporters or checkers who are capable of confirming its correctness.
I could not trust that the program is doing the right thing for
anything else - there could be countless other small subtle things that
would go wrong with perfectly good C code. (Looking through the issues
for the project, it seems this is definitely the case.)

Don't misunderstand me here - I have no reason to demand or expect that
the Pico C author should only write quality tools that conform
accurately to the C standards. He/she could have written a simple
little tool, and published it for others to play with. And maybe it is
good enough for some uses. But it is not of the quality I would want
for a language tool - at least not without clear information and
documentation about its limitations.

I have filed this issue with Pico C, despite the project being dead, so
that anyone considering using it can see the problem.