Почему при присваивание непосредственно числа все нормально ( B = 13 ), а при присваивании другово bool ( B2 = B ) мусор остается?
Так и должно быть?

Вероятно, компилятор производит преобразования типа при присвоении bool = не_bool. А при присвоении bool=другой_bool он считает, что всё уже преобразовано до того, и не проверяет. Вы же, своим хитрым хаком


избежали проверки при присвоении значения переменной типа bool, и перехитрили компилятор.

явное преобразование типа тоже не помогает:

В каждом компиляторе работа с bool может быть организована по-разному. Ваш компилятор очевидно конверсию в bool производит на этапе присваивания, а работает с bool-переменными, используя только их младший бит. Такой подход эффекитивен при компиляции, т.к. упрощает булевские операции, позволяя делать их "не глядя". В противном случае приведение типа пришлось бы делать при каждой булевской операции с ее использованием.
Таким образом "мусор" не мешает работе программы, поскольку все остальные биты, кроме младшего, в работе не участвуют.

B2 = (int)( B ) ; ?

Явное преобразование типов указателей - это всегда очень опасная операция с возможно непредсказуемыми побочными эффектами. Ответственность за правильный результат лежит целиком на программисте, который должен понимать что делает. Компилятор же больше ни за что не отвечает. Если Вы не понимаете что хотите сделать и как будет результат интерпретирован - зачем пользуетесь такой опасной операцией? Взяли спички в руки, поигрались и удивляетесь, откуда пожар...

Если бы не мешали я бы может и не заметил:
выводит только "true"

я в этом вижу потенциальную проблему, например, при чтении бинарного файла данных.Придется производить доп. операции, что бы избавиться от мусора:

Я уже объясняла, что сложности с набитыми мусором булевскими переменными возникают исключительно при проведении булевских операций над ними, что заставляет компилятор во имя эффективности использовать только младший бит этого числа. Однако при проверке булевой переменной (например для ветвления по оператору if) такой проблемы не возникает, и тут компилятор проверяет переменную "честно". Это потому, что поверка одного бита "стоит" ровно столько же, сколько проверка всех битов - тестирование регистра на нулевое значение занимает столько же инструкций, как и тестирование одного его бита. А вот булевские операции (типа ! ~ ^ & |) над одним битом производятся элементарно, а над мусорными переменными нет.



- тут B тестируется на ненулевое значение, а потому ЛЮБОЕ ненулевое значение B напечатает true.



- а тут операция B = !B компилируется экономно - инверсией младшего бита. Можно было бы сразу инвертировать все биты числа, но мусор от этого останется мусором, но в false не превратится.
Попробуйте сами вместо компилятора оттранслировать B = !B. Тогда поймете, что без ветвления по if/else этого сделать нельзя.



Избавляться от мусора короче так:
B = B ? true : false;

Естественно придется. Но несколько иначе:
Все. Компилятор знает, как преобразовать внутреннее представление uint8_t во внутреннее представление bool. Не надо мешать ему, пытаясь сделать его работу через неявное преобразование при помощи указателей. А если в вашем компиляторе bool будет 32 бита, что вы считаете из файла вашим методом?


Еще раз: каким образом вы присвоили B значение 13? Оператором B = 13 вы не можете присвоить переменной типа bool значение, отличное от true и false. Если вы присвоили через указатель на другой тип - это жульничество, и компилятор ведет себя как считает нужным. Ибо запись B = 13 фактически означает B = bool(13), и 13 в B ну никак попасть не сможет.

А кто сказал что можно недостаточно четко специфицированное бинарное представление с одного компа на другой переносить? Попробуйте перенести даже обычные целые числа с little-endian на big-endian машины. Не говоря уже про указатели Такова уж жизнь - про внешнее представление нужно думать особо, чтобы не получать неожиданности.

...посмотрите в дизассемблере код который соответствует этому фрагменту



Так и должно быть, потому что тип bool предполагает использование преопределенных констант для данной реализации компилятора.

у меня собственно так и есть, универсальность эта другая тема.


да жульничество, но интервейс вызова Read(void* Buff, int N) достаточно широко используется, есть и другие варианта попадание мусора в bool. Но проверять значение после подозрительных мест надо обязательно.
Потом такой момент, если используется swtich, пусть даже с параметром enum, все равно в голове помним о левых значениях, которые обработаем default. При работе с bool переменными думается true/false, а там может и вигная какая то быть, причем "заразная", передается присваиванием ( B2 = B1 ).
А явное преобразование B = (bool)( B ) по моему, должно работать четко.

B = (bool)(int)( B )

Судя по тому, что вы подключаете в проект файл stdbool.h - тип bool не встроен в компилятор, а реализован через некоторое переопределение, типа
#define bool int

или что-то типа того. Не во всех компиляторах bool - встроенный тип. А был бы встроенным, не надо было никакого файла дополнительно инклюдировать.

Если компилятор соответствует стандарту С99, то он должен иметь

• встроенный тип _Bool с рангом ниже любого целочисленного типа, способный вместить 0 и 1, при приведении любого скалярного значения к _Bool оно приводится как (val == 0 ? 0 : 1)
• стандартный включаемый файл stdbool.h, который определяет
  #define bool _Bool
  #define true 1
  #define false 0

Так что если обсуждаемая ситуация касается С99-режима компиляции и bool не переопределён пользователем, то после
в b будет корректное значение, ну а
как уже говорилось - неконтролируемая компилятором порнография, приводящая к UB.
И при
компилятор не обязан ничего проверять и "переприводить" - он не виноват, что в b левыми путями натолкали мусор.
Частными случаями UB может быть и ожидаемое программистом поведение, и совершенно противоположное.
должно бы работать правильно, но не лучше ли обойтись без извращений?

Это для очень многих процессоров не правда! Во многих случаях проверка на нулевое значение быстрее(инструкция меньше места занимает) или вообще не требует инструкции!

К тому же очень полезно смотреть листинги, на максимальной оптимизации! И будет видно как компилер работает с булевыми переменными.

Что-то меня сомнения гложат. Тогда уж и вылезать через ту же дырку,через которую влезли:

Угу. Для чтения тех же типов данных, которые были записаны при помощи Write(void* Buff,int N).

Использование выражений типа

само по себе вроде и не страшно, но неправильно, потому как проверять по равенству/неравенству действительно можно только на false


Использую чуть другие буквы и не использую файл stdbool.h

Последняя строчка априори верна. true в таком случае опять же равно +1.
Но, IMHO, использование в Си беззнаковых типов для bool и положительного значения для true это какая-то диверсия, что ли. Из знакового в беззнаковое преобразовать практически всегда возможно, а вот наоборот нет. Использую знаковое представление.

Хотя это, если таки пытаться делать проверку на true, вылазит боком при использовании структур с битовыми полями объявленного знакового типа bool. Тогда компилятор при знаковом целом типе для bool считает значение поля не как 1, а как -1, а сравнение с true просто никогда не работает (ну и не очень-то и хотелось).