Is bool no longer a primitive data type of C/C++ ?

[olcott]

Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1 for x86
requires the following header or bool function_name() will not compile:
#include <stdbool.h>

I am guessing the this is simply a Microsoft screw up because online
documentation seems to indicate that bool is a primitive data type in
recent standards for the C programming language.


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[Bonita Montero]

Am 02.11.2020 um 17:31 schrieb olcott:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1 for x86
> requires the following header or bool function_name() will not compile:
> #include <stdbool.h>
> I am guessing the this is simply a Microsoft screw up because online
> documentation seems to indicate that bool is a primitive data type in
> recent standards for the C programming language.

AFAIK bool isn't a native type in C but you have to include <stdbool.h>.
In C++, bool is a native type.

[olcott]

Native Data Types
Special type: bool (has values true and false)

https://www.cs.fsu.edu/~lacher/lectures/Output/cppreview/slide02.html

[Alf P. Steinbach]

The built-in type in C is called `_Bool`.

<stdbool.h> adds the `bool` alias, as well as `true` and `false`.


Cheers,

- Alf

[olcott]

I have been a C programmer since K&R was the standard when did they make
this change?

[Mike Terry]

On 02/11/2020 16:31, olcott wrote:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1 for x86
> requires the following header or bool function_name() will not compile:
> #include <stdbool.h>
>
> I am guessing the this is simply a Microsoft screw up because online
> documentation seems to indicate that bool is a primitive data type in
> recent standards for the C programming language.
>
>

bool is not a native type in C.

<https://en.wikipedia.org/wiki/C_data_types#Boolean_type>

There is a native type _Bool. (Note "true" and "false" are not native
in C either - you must assign an integral type - assigning a non-zero
integer results in a stored _Bool value of 1.)

Mike.

[Bonita Montero]

>> AFAIK bool isn't a native type in C but you have to include <stdbool.h>.
>> In C++, bool is a native type.

> Native Data Types
> Special type: bool (has values true and false)
> https://www.cs.fsu.edu/~lacher/lectures/Output/cppreview/slide02.html

That refers to C++ ("1. Basic C++: A Review - 2 of 21").

[Joe Pfeiffer]

olcott <No...@NoWhere.com> writes:

> Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1 for x86
> requires the following header or bool function_name() will not compile:
> #include <stdbool.h>
>
> I am guessing the this is simply a Microsoft screw up because online
> documentation seems to indicate that bool is a primitive data type in
> recent standards for the C programming language.

The draft I've got of the C18 standard (N2346) has the following:

7.18 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.

(and then goes on to define true and false).

_Bool, on the other hand, is a keyword and a "real" type.

I expect (someone who knows better is welcome to correct me) the reason
it was done this way instead of simply defining a new type "bool" was to
avoid breaking old code that had its own definition of bool.

[Bonita Montero]

> The draft I've got of the C18 standard (N2346) has the following:
>
> 7.18 Boolean type and values <stdbool.h>
> 1 The header <stdbool.h> defines four macros.
> 2 The macro
> bool
> expands to _Bool.

You don't need C18 for this. This features are included in C99.

[olcott]

If bool is not a native type in C then they must have changed this at
some point after K&R C. Exactly when was this changed?

[Bonita Montero]

>> bool is not a native type in C.
>> <https://en.wikipedia.org/wiki/C_data_types#Boolean_type>
>> There is a native type _Bool.  (Note "true" and "false" are not native
>> in C either - you must assign an integral type - assigning a non-zero
>> integer results in a stored _Bool value of 1.)

> If bool is not a native type in C then they must have changed this at
> some point after K&R C. Exactly when was this changed?

bool has never been a native Type in any version of C.

[olcott]

So then C99 changed the K&R standard of bool as a native type?

[olcott]

Florida State University university says that it is a native type now:

Native Data Types
Special type: bool (has values true and false)

https://www.cs.fsu.edu/~lacher/lectures/Output/cppreview/slide02.html

[Bonita Montero]

>> bool has never been a native Type in any version of C.

> Florida State University university says that it is a native type now:
> Native Data Types
> Special type: bool (has values true and false)
> https://www.cs.fsu.edu/~lacher/lectures/Output/cppreview/slide02.html

Look at the bottom: "1. Basic _C++_: A Review".

[Bonita Montero]

>> You don't need C18 for this. This features are included in C99.

> So then C99 changed the K&R standard of bool as a native type?

bool isn't a native type in any C-standard, even not in K&R C.

[olcott]

OK I am convinced. I have switched to C++ such a long time ago that I
forgot this difference between C and C++.

The C99 standard for C language supports bool variables. Unlike C++,
where no header file is needed to use bool, a header file “stdbool.h”
must be included to use bool in C.

https://www.geeksforgeeks.org/bool-in-c/

[Joe Pfeiffer]

olcott <No...@NoWhere.com> writes:

> On 11/2/2020 10:48 AM, Alf P. Steinbach wrote:
>>
>> The built-in type in C is called `_Bool`.
>>
>> <stdbool.h> adds the `bool` alias, as well as `true` and `false`.
>>
>>
>> Cheers,
>>
>> - Alf
>
> I have been a C programmer since K&R was the standard when did they
> make this change?

The oldest copy of he standard I have is N1256, for C99. _Bool and
stdbool.h are in that standard.

[Bonita Montero]

What I'm curious about is: why is bool in <stdbool.h> a macro and
not a typedef of _Bool ? For my taste the latter one would have
been the cleaner solution.

[olcott]

Yes. I have switched to C++ for such a long time that I forgot that the
original purpose of C was to create a portable language that was
efficient enough to use to implement Unix. In other words when we
construe C as a higher level assembly language then bool as a native
type does not make sense.

[olcott]

I think that I still have the original lying around somewhere.

[James Kuyper]

The "Subject:" header demonstrates the pitfalls of talking about the
non-existent "C/C++" language. bool is not now, and never has been, a
primitive type in C. bool is now, and always has been, a primitive type
in standard C++ (I think it might have been a typedef or macro in some
of the older pre-standard versions of C++).

The built-in type _Bool was added to C in C99, along with a header
(<stdbool.h>) that declares 'bool' as a macro expanding to _Bool. None
of those things were part of K&R C, nor C90.

[Scott Lurndal]

Bonita Montero <Bonita....@gmail.com> schrieb:

>What I'm curious about is: why is bool in <stdbool.h> a macro and
>not a typedef of _Bool ? For my taste the latter one would have
>been the cleaner solution.

The macro, not being a language feature, can be #undef'd if necessary
in legacy C headers that already were using a typedef for 'bool'.

[olcott]

Thanks for this very thorough answer.

[David Brown]

On 02/11/2020 19:17, olcott wrote:
> On 11/2/2020 11:14 AM, Bonita Montero wrote:
>>>> You don't need C18 for this. This features are included in C99.
>>
>>> So then C99 changed the K&R standard of bool as a native type?
>>
>> bool isn't a native type in any C-standard, even not in K&R C.
>>

_Bool is a native type in C, added in C99. Like bool in C++, it has
distinct properties unlike other integer types of the same size
(typically, but not necessarily, it is one byte in size - which is
typically, but not necessarily, 8 bits). In particular, it can only
ever hold the value 0 or 1. (Compilers know this, and take advantage of
that in optimisation.) Assignment "_Bool b = x;" is treated exactly as
"b = (x == 0) ? 0 : 1;"

>
> Yes. I have switched to C++ for such a long time that I forgot that the
> original purpose of C was to create a portable language that was
> efficient enough to use to implement Unix.

Correct.

> In other words when we
> construe C as a higher level assembly language

Wrong. C was designed to reduce the need to write assembly, not to be a
"high level assembly".

> then bool as a native
> type does not make sense.
>

A native boolean type would always have made sense. But C was a smaller
language when it was created, and gained new useful features as the
language, tools, and use of the language grew and matured.

[David Brown]

"bool", "true" and "false" are valid identifiers in C, and so making
them keywords in C99 would have broken existing code. (C++ had them as
keywords since the language was created - also, C++ is more willing to
risk breakage in existing code than C is in new standards.)

_Bool, on the other hand, is an identifier reserved for the
implementation - new keywords are therefore almost always given _Keyword
style names in C. And they are usually matched with a new <std...>
header that defines "keyword" as a macro for "_Keyword", along with any
other convenient types, macros, functions, etc., for the new feature.

The definitions in standard headers are usually macros, so that people
can #undef them if they want for compatibility with old code.

[daniel...@gmail.com]

On Monday, November 2, 2020 at 4:48:33 PM UTC-5, David Brown wrote:

> "bool", "true" and "false" are valid identifiers in C, and so making
> them keywords in C99 would have broken existing code. (C++ had them as
> keywords since the language was created

Not in its original specification, bool was added during ISO/ANSI standardization.
I recall reading an article in C++ Report that talked about the compromises
that were made to break as little code as possible that already used #define bool int,
comprises that included (regrettably, in my opinion) the integer conversions.

Daniel

[David Brown]

On 02/11/2020 23:51, daniel...@gmail.com wrote:
> On Monday, November 2, 2020 at 4:48:33 PM UTC-5, David Brown wrote:
>
>> "bool", "true" and "false" are valid identifiers in C, and so making
>> them keywords in C99 would have broken existing code. (C++ had them as
>> keywords since the language was created
>
> Not in its original specification, bool was added during ISO/ANSI standardization.

Fair enough.

> I recall reading an article in C++ Report that talked about the compromises
> that were made to break as little code as possible that already used #define bool int,
> comprises that included (regrettably, in my opinion) the integer conversions.
>

A lot of C++ would have been a neater, safer and stronger language if it
had had fewer compromises to be compatible with C.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
> "bool", "true" and "false" are valid identifiers in C, and so making
> them keywords in C99 would have broken existing code. (C++ had them as
> keywords since the language was created - also, C++ is more willing to
> risk breakage in existing code than C is in new standards.)

[...]

That's not quite true. C++ has had bool as a builtin type, and false
and true as keywords, since its first ISO standard, in 1998. But the
first and second editions of Stroustrup's "The C Programming Language"
(1986 and 1991, respectively) don't mention bool, and for example
document that the "!" operator yields a result of type int with the
value 0 or 1.

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

[olcott]

On 11/2/2020 6:05 PM, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
>> "bool", "true" and "false" are valid identifiers in C, and so making
>> them keywords in C99 would have broken existing code. (C++ had them as
>> keywords since the language was created - also, C++ is more willing to
>> risk breakage in existing code than C is in new standards.)
> [...]
>
> That's not quite true. C++ has had bool as a builtin type, and false
> and true as keywords, since its first ISO standard, in 1998. But the

Yes for C++, not for C.

> first and second editions of Stroustrup's "The C Programming Language"
> (1986 and 1991, respectively) don't mention bool, and for example
> document that the "!" operator yields a result of type int with the
> value 0 or 1.
>


--

[Bonita Montero]

> The macro, not being a language feature, can be #undef'd if necessary

> ...

Why should someone include <stdbool.h> and undef bool ?

[David Brown]

On 03/11/2020 01:05, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
>> "bool", "true" and "false" are valid identifiers in C, and so making
>> them keywords in C99 would have broken existing code. (C++ had them as
>> keywords since the language was created - also, C++ is more willing to
>> risk breakage in existing code than C is in new standards.)
> [...]
>
> That's not quite true. C++ has had bool as a builtin type, and false
> and true as keywords, since its first ISO standard, in 1998. But the
> first and second editions of Stroustrup's "The C Programming Language"
> (1986 and 1991, respectively) don't mention bool, and for example
> document that the "!" operator yields a result of type int with the
> value 0 or 1.
>

Yes, another poster (Daniel) pointed that out. (I have the second
edition of the book on my shelf, but it's a /long/ time since I read it.)

[David Brown]

Because they include one header that itself uses <stdbool.h>, and
another that defines its own "bool" type? You won't (or shouldn't) get
this kind of thing in newly written headers - even if code is written to
C90 standards it should not knowingly use identifiers that conflict with
newer C code. But it's possible that you get such troubles when using
older code and newer code together, so the C standards committee use
macros to let people work around such issues without having to change
the old (and presumably tested and working) code.

[Bonita Montero]

> Because they include one header that itself uses <stdbool.h>, and

> another that defines its own "bool" type? ...

Why should I confuse with my code by defining bool differently ?

[David Brown]

/You/ would not do so - because you write C++ code, and you do so today
using relatively modern standards. But someone else may have written C
code last century, or at least C90 code, and used their own "bool" type.
And if a C programmer needs to use that old (or old standard) code
along with modern code that uses <stdbool.h>, then "#undef bool" could
be part of their solution.

[Bonita Montero]

> /You/ would not do so - because you write C++ code, and you do so today
> using relatively modern standards. But someone else may have written C
> code last century, or at least C90 code, and used their own "bool" type.
> And if a C programmer needs to use that old (or old standard) code
> along with modern code that uses <stdbool.h>, then "#undef bool" could
> be part of their solution.

It could be better to spend 5mins by sarch & replace the custom bool
-type with a different name to prevent confusion by others who read
the source.

[Bo Persson]

Yes, unless you can't.

For example if some of the code is used in medical equipment and any
source change would need recertification in several different countries.

Then it would be *a lot* less expensive to use your old headers in new
code, and just undef the conflicting macros.



Bo Persson

[Bonita Montero]

> For example if some of the code is used in medical equipment and any
> source change would need recertification in several different countries.

You're joking.
The code has the same functionality, no matter what this type is called.

[David Brown]

Don't worry about it. You can use bool. Leave the difficult
development issues to people who know about them.

[Bonita Montero]

>> You're joking.
>> The code has the same functionality, no matter what this type is called.

> Don't worry about it. You can use bool. Leave the difficult
> development issues to people who know about them.

If there's a need to read the code, there's surely a need to change
it anyway. So if someone gets confused by a mis-typed bool because
of a #undef / re-#define, there's no problem with aliasing the own
type with a unique name.
The whole argumentation is ridiculous. It's like saying uint**_t
has to be a macro because it could be redefined.

[David Brown]

On 03/11/2020 15:56, Bonita Montero wrote:
>>> You're joking.
>>> The code has the same functionality, no matter what this type is called.
>
>> Don't worry about it.  You can use bool.  Leave the difficult
>> development issues to people who know about them.
>
> If there's a need to read the code, there's surely a need to change
> it anyway.

As I said - if you don't understand why some development practices
require that you do not change the code without exceptional reason,
leave such serious development to other people.

In certain fields, such as medical devices, parts of automotive
development, aeronautic development, and the like, if code has been
tested and certified, it does not change.

For example, a bug was found in the engine management code for the
dreamliner aircraft engines which would cause the engine to stop after
about 400 days (IIRC). It was cheaper and lower risk to add a "restart
the engine controller every 120 days" requirement to the maintenance
manuals than to fix the bug - despite the bug fix being trivial in the code.

Do you think developers in such conservative processes will change the
code in the headers to avoid confusion, or add an #undef and document
the strangeness in the code?

The programming world does not consist solely of windows apps which
treat users as beta testers. There are programmers who would consider a
half-dozen lines of code in a week to be unusually productive. You do
not change such code lightly.

[Bonita Montero]

> As I said - if you don't understand why some development practices
> require that you do not change the code without exceptional reason,
> leave such serious development to other people.
> In certain fields, such as medical devices, parts of automotive
> development, aeronautic development, and the like, if code has been
> tested and certified, it does not change.

You don't understand what I've said. As long as no one will read the
code there's no confusion about redefined bools. But if someone will
read the code it's very likely that there's also a need to change it.
And when change it, you can remove this bool-alias-confusion in a
minute.

[Scott Lurndal]

You have no clue what's involved in real software development, it
appears.

[Bart]

On 03/11/2020 16:25, David Brown wrote:
> On 03/11/2020 15:56, Bonita Montero wrote:
>>>> You're joking.
>>>> The code has the same functionality, no matter what this type is called.
>>
>>> Don't worry about it.  You can use bool.  Leave the difficult
>>> development issues to people who know about them.
>>
>> If there's a need to read the code, there's surely a need to change
>> it anyway.
>
> As I said - if you don't understand why some development practices
> require that you do not change the code without exceptional reason,
> leave such serious development to other people.
>
> In certain fields, such as medical devices, parts of automotive
> development, aeronautic development, and the like, if code has been
> tested and certified, it does not change.
>
> For example, a bug was found in the engine management code for the
> dreamliner aircraft engines which would cause the engine to stop after
> about 400 days (IIRC). It was cheaper and lower risk to add a "restart
> the engine controller every 120 days" requirement to the maintenance
> manuals than to fix the bug - despite the bug fix being trivial in the code.
>
> Do you think developers in such conservative processes will change the
> code in the headers to avoid confusion, or add an #undef and document
> the strangeness in the code?
>
> The programming world does not consist solely of windows apps which
> treat users as beta testers.

You're singling out windows apps unfairly.

I've seen considerable numbers of bugs in apps across Android and
whatever passes for an OS in smart TVs. And in my car (causing it to not
restart after an auto engine cuttoff, or make the satnav go crazy).

May applications are just ambitious or too many layers of software where
one part doesn't what another is doing.

(Whenever I plan to watch TV during a meal I've taken to setting it up
beforehand so that it doesn't go cold while sorting out network and
operational problems.)

And when it's not actual bugs, the user interfaces are generally
temperamental.

That 'restart every 120 days' requirement is similar to any workaround a
an applications developer will advise a client until a problem is
sorted. You identify a problem, but acknowledge also that a client needs
to be getting on with their work. And it is common that a too-quick fix
can screw other things.

[Bonita Montero]

Nothing what you say is related to what I said.

[Richard Damon]

The big difference is that it is very unlikely for code written before
C99 propsed these types, for code to have used those types. Prior to C99
there were a lot of types invented for these purposes, but they used
other names. In one sense, the standard avoided some of the perhaps
'better' names to avoid conflict, and leave room for applications to
continue to use those other names.

bool, on the other hand was a VERY largely imlemented type, as it is so
fundamentally natural. The name bool, is also by far the most natural
name. It also has special properties that can't be emulated by other
types easily in C (like all non-zero values become 1).

Because of this, it was useful to make it a way that code could 'erase'
the definition, and rather than defining an typeundef statement, they
made it a macro.

bool is also a name not likely to be used in another context, where
restricting the scope of the definition would likely make a difference
(because people DID think of it as sort of a reserved word, that just
hadden't been implemented, so they did it).

[David Brown]

I'm not sure it is unfair to suggest that Windows programs are often
more poorly coded. But it was not my intention to suggest that /only/
Windows programs are badly written (or badly tested, or otherwise badly
developed) - or that this applies to all programs on Windows. But it is
my understanding that Bonita writes general Windows programs, which was
why I mentioned them.

[daniel...@gmail.com]

On Tuesday, November 3, 2020 at 2:07:58 PM UTC-5, David Brown wrote:
> I'm not sure it is unfair to suggest that Windows programs are often
> more poorly coded. But it was not my intention to suggest that /only/
> Windows programs are badly written (or badly tested, or otherwise badly
> developed) - or that this applies to all programs on Windows. But it is
> my understanding that Bonita writes general Windows programs, which was
> why I mentioned them.

Right, you felt it necessary to make an ad hominem attack on Bonita. But why
the ad hominem attack?

Daniel

[David Brown]

I was attacking Bonita's attitude in this matter, not her directly. And
a suggestion that general Windows programming is not done with the
development quality and care that is used in medical devices, automotive
industries, etc., is not an attack - it is simple fact. I would hope
most people understand that. If not, apply a little thought and I'm
sure it will be obvious.

There are far more types of programming and software development than
most people realise - even programmers who have worked professionally in
a range of fields for decades will be unaware of how things are done in
the majority of different branches. So when people make assumptions
about "no one needs to do that" or "no one /should/ do that", regardless
of the type of development, they are usually wrong. Simple ignorance is
easy to cure - you give the person a little more information. Wilful
ignorance - the kind that ridicules the idea of having a use for "#undef
bool" - is harder to handle.

[daniel...@gmail.com]

On Wednesday, November 4, 2020 at 3:11:44 AM UTC-5, David Brown wrote:
> >
> I was attacking Bonita's attitude in this matter, not her directly.

A distinction without a difference, an ad hominin attack is an ad hominin
attack. Stroustrup once posted that a plea for civility can never be entirely
off topic, it is in that spirit that I offer this one.

Daniel

[Juha Nieminen]

In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> For example, a bug was found in the engine management code for the
> dreamliner aircraft engines which would cause the engine to stop after
> about 400 days (IIRC). It was cheaper and lower risk to add a "restart
> the engine controller every 120 days" requirement to the maintenance
> manuals than to fix the bug - despite the bug fix being trivial in the code.

I find it a bit hard to believe that such a "fix" would be approved by
the aviation authorities.

It's essentially saying "we know that our aircraft can suffer a
catastrophic failure, therefore the software must be restarted by
maintenance every 120 days". Instead of fixing the bug, it just
relies on the maintenance personnel, human beings, always remembering
to follow that particular step, everywhere, for hundreds of airplanes,
for years and years to come.

One day that step will fall through the cracks due to human error.
The mainenance crew may accidentally skip doing it because of one of
a myriad of possible reasons. Then 400 people might die in a horrific
accident. Can the aircraft manufacturer then use the excuse "yeah, we
knew about the bug, and we knew how to fix it, but we just put an
instruction in the maintenance manual to kludge around the bug. It's
not our fault, it's the fault of the mainenance personnel. They should
have followed the kludge instruction."

If there's one thing about the aviation industry is that they don't
really like to leave anything to chance. If something can be made
safer, they will demand it to be made safer. There's a reason why
the validation process for any changes to aircraft is so long and
arduous.

[Juha Nieminen]

In comp.lang.c++ Bart <b...@freeuk.com> wrote:
> I've seen considerable numbers of bugs in apps across Android and
> whatever passes for an OS in smart TVs. And in my car (causing it to not
> restart after an auto engine cuttoff, or make the satnav go crazy).

Embedded systems are often ridden with bugs. One of the main reasons for
this is that in the embedded industry there's a general aversion towards
developing your own software and instead there's a tendency to use
existing third-party code, and a general false trust on the validity of
that code. If there exists an existing library or program for a particular
task, there's often a general tendency to want to use it, rather than
develop it from scratch.

Yes, even if it's just some random code from some random nobody on github.
I kid you not.

But even if it's a relatively popular library, there's still no guarantee
that there are no serious bugs in it. But most of the industry just blindly
trusts that's so.

(It's almost scary when the code is so buggy that even the *compiler*
itself gives warnings about those bugs. How many bugs there may be that
the compiler doesn't see?)

[Richard Damon]

You may find it hard to believe, but I do believe this is referencing a
factual case that HAS happened. (The time period was about 248 days, or
2**31 * 10ms)

One key feature to remember is that normal procedures would have that
controller shut down periodically for various types of maintenance long
before that point, so there isn't that much need for a 'special
procedure' to do this. The actual protocal adopted was to force a
restart at about 1/2 that time (120 days) so the step would have to have
been missed for about 3 months.

It also should be noted that they ARE working on a software fix for
this, probably tied with a lot of other changes they want to make, but
it WILL take a while for the fix to make it out (and it may have
actually been made by this time, this was a number of years ago). The
issue was that it takes a long time to re-certify the software to be
air-worthy.

[red floyd]

You have made the common mistake of assuming that your use case
is the only one that is needed.

[Bonita Montero]

>>>> You don't understand what I've said. As long as no one will read the
>>>> code there's no confusion about redefined bools. But if someone will
>>>> read the code it's very likely that there's also a need to change it.
>>>> And when change it, you can remove this bool-alias-confusion in a
>>>> minute.

>>> You have no clue what's involved in real software development, it
>>> appears.

>> Nothing what you say is related to what I said.

> You have made the common mistake of assuming that your use case
> is the only one that is needed.

It is. There's no need to read a source without changing it.

[David Brown]

On 04/11/2020 14:32, Juha Nieminen wrote:
> In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
>> For example, a bug was found in the engine management code for the
>> dreamliner aircraft engines which would cause the engine to stop after
>> about 400 days (IIRC). It was cheaper and lower risk to add a "restart
>> the engine controller every 120 days" requirement to the maintenance
>> manuals than to fix the bug - despite the bug fix being trivial in the code.
>
> I find it a bit hard to believe that such a "fix" would be approved by
> the aviation authorities.
>

Of course the long-term fix is to correct the software.

> It's essentially saying "we know that our aircraft can suffer a
> catastrophic failure, therefore the software must be restarted by
> maintenance every 120 days". Instead of fixing the bug, it just
> relies on the maintenance personnel, human beings, always remembering
> to follow that particular step, everywhere, for hundreds of airplanes,
> for years and years to come.

Aircraft maintenance is done very rigorously, with lots of checklists.
These things don't get forgotten.

>
> One day that step will fall through the cracks due to human error.
> The mainenance crew may accidentally skip doing it because of one of
> a myriad of possible reasons. Then 400 people might die in a horrific
> accident. Can the aircraft manufacturer then use the excuse "yeah, we
> knew about the bug, and we knew how to fix it, but we just put an
> instruction in the maintenance manual to kludge around the bug. It's
> not our fault, it's the fault of the mainenance personnel. They should
> have followed the kludge instruction."
>
> If there's one thing about the aviation industry is that they don't
> really like to leave anything to chance. If something can be made
> safer, they will demand it to be made safer. There's a reason why
> the validation process for any changes to aircraft is so long and
> arduous.
>

Sure. But it is precisely because of such an attitude that you can't
simply fix the bug.

The development people will of course fix this bug. Then they will put
the new version on boards for long-term testing. They will not ship the
new software until it has undergone perhaps months of automated testing.
In the meantime, any new engines made will get the known bad software.

Known bugs like this are not a big risk - because the workaround is
clear and reliable. It is unknown bugs that are the risk.

[Sjouke Burry]

Why not reboot when the plane shuts down, even if daily?
Which safety guy has decided that it is "a good idea" to
leave things running for weeks or months?
I would accuse myself of stupidity if I used my computers that way.

[Richard Damon]

Apparently this part of the system is fairly regularly left running
between flights and even over night, in part because a reboot of this
system takes a while to perform. Sort of like how a lot of people whill
just put their computer to sleep overnight, as opposed to shutting down
and rebooting in the morning.

It sounds like while it is common to shut it down for most maintenance,
it doesn't always happens that way, and while it is very unlikely for
the plane to have hit the 120 day mark without a reboot, it was worth
adding that as an item in the maintenance check list.