Задавал тип uint8_t для строк. Надоело. Показалось малоинформативным. Решил писать char. Теперь при использовании старых функций выскакивают варнинги о несоответствии типов. Надо выбрать что-то одно. Что посоветуете?

Естественно, char. А то наткнетесь где нибудь, что char 16-битный, uint8_t - 8 битный, и на кучу глюков по этой причине с ф-циями стандартной библиотеки.

Естественно char. Строка состоит из символов, char хранит символ. И это единственное, для чего использую char - именно когда надо хранить символ (строку символов). Когда нужен байт - использую (u)int(_fast)8_t, а когда нужен указатель на область памяти, в которой может быть что угодно (для передачи, приема, побайтовой отладочной распечатки) - void (const) *, использую неявное приведение любого указателя к void (const) * и уже внутри соотвествующей функции привожу к указателю на байт:


Предупреждений нет.

Ну, если плюсы, то лучше наверное так:

?

Наверное лучше. Но писанины больше да и путаюсь я в этих static_cast, reinterpret_cast, const_cast.

Спасибо всем. Так и буду делать. Вопрос 16-битового char, видимо, все же, не стоит. На то есть wchar. А вот signed/unsigned - есть разногласия у компиляторописателей.
Все, дошел до осознания писать на C++ для микроконтроллеров. Сложность программы сама к этому подталкивает, безо всяких холиваров.

Это Вы недопоняли суть... Есть такие архитектуры, где размер char равен размеру wchar_t, и оба 16-битные. И, если на этой архитектуре реализован тип int8_t, то, если строку объявить как int8_t, что-то с ней поделать как с массивом, а потом использовать какой-нибудь стандартный strcmp, то будет смачный глюк из серии "хрен найдешь".

Слава богу, что я не знаком с такими архитектурами. Там, наверное, все типы по 16 битов?
Я когда-то решил, что char уже анахронизм. Был неправ.

Нет. Там, в основном все по 32 бит, и бывают long-long-и по 40 бит. Это, конкретно, TMS320VC55xx