Я думаю, что Вы правы , спорить не буду. В тонкостях Си я еще не силен.
Уточнился по борладндовскому хэлпу (Билдер), там сказано что и char по умолчанию знаковый. В IAR-е видимо для таких как я галочку поставили, чтоб хоть с char поначалу не заморачиваться. Привыкли, что в железе знаков нет.

Уточнился по борладндовскому хэлпу (Билдер), там сказано что и char по умолчанию знаковый. В IAR-е видимо для таких как я галочку поставили, чтоб хоть с char поначалу не заморачиваться. Привыкли, что в железе знаков нет.
В любом мало-мальски приличном букваре по С сказано - не закладываться на знаковость char вообще - нигде и никогда, ни явно, ни неявно.
Вот писатели пикада не подумали об этом где-то пропустили при чтении ASCII-формата входящие симовлы через char - и мы имеем облом на русской букве "я" - код 0xFF, который при пропускании через знаковый char в int превращается в полновесный -1 и мы имеем unexpected end of file на строке "схема электрическая принципиальная" - надо большими буквами писать. Естественно, это моё предположение, но больно оно правдоподобно выглядит.
Так о чём это я... А! Так вот, любая приличная книга говорит - если знак важен - указывать явно unsigned char или signed char - в зависимости от того, что надо.
У меня тип char если используется - то это явное предупреждение для меня же более позднего - "тут хранятся не более чем символы, никакой арифметики, сравнение только с символьными константами на равенство"
А стандарт языка С 99-го года заводит стандартный заголовочный файл stdint.h , в котором должны через typedef определяться типы int8_t uint8_t ... int64_t uint64_t.
Я бы рекомендовал пользоваться этими типами, а не byte/word/dword (особенно учитывая то, что word на x86 - это halfword на ARM, dword на x86 - это word на ARM).
Если stdint.h в поставке имеющегося компилятора нет - несложно написать и приложить самому.
Что я во всех новых проектах и делаю уже года 4. И даже один старый, но развивающийся - не поленился со старых i08/u08/../i32/u32 пере-sed-ить на новые стандартные typedef-ы.