Вот именно: кроме собственно адреса такой указатель содержит искусственно введенную дополнительную информацию. По одному только адресу ("чистому" указателю) определить, к какому адресному пространству нужно обращаться, невозможно.

Подумал и уточню: искуственно введенную информацию на этапе исполнения. В случае использования дублирующих функций для доступа к другим адресным пространствам имена (=адреса вызова) этих функций также будут дополнительной информацией, но уже на этапе компиляции. Как и специальные квалификаторы вроде __flash. За исключением очень редких случаев предпочтительнее использование информации этапа компиляции, т.к. это дает более оптимальный как по времени исполнения, так и по размеру, код.
P.S. для разрешения на этапе исполнения iar тоже имеет специально обучнный квалификатор указателей generic. avr-gcc не имеет встроенной в компилятор поддержки различных адресных пространств, только через макросы библиотеки avr-libc.

Это мне прекрасно понятно. Я уточню вопрос. Тут кто-то говорил что будут проблемы с русской кодировкой или что-то в этом духе. Так вот я немогу понять где эти проблемы? Я не говорю о типе char как о типе данных для представления чисел (с этим всё кристально ясно), я говорю лишь о строках и символах. При работе с буковками я никогда не думаю об их "цифровом коде" - это вредно для мозга, я думаю лишь об их взаимном расположении в кодовой таблице.
Ведь ряд чисел для типа char со знаком получается такой: 0,1,...126,127,-128,-127,...-2,-1
И даже если я попытаюсь сравнить символ на попадание в диапазон, границы которого лежат в левой и правой половинках ряда, то всё будет хорошо. Псевдокод: if (ch>126)&&(ch<-127) {} - это полностью соответствует if (ch>126)&&(ch<129) {} в случае когда char без знака. И если в этих выражения стоят не конкретные числа, а как я уже говорил у меня там _всегда_ что то типа 'А' и 'Я' - то всё будет хорошо А меня пытаются убеждать в обратном, но я не сдаюсь.

если char знаковый, то if(char_code < 'А') /* cyrilic 'A' */ работает с точностью до наоборот от ожидаемого.

Ошибаетесь. Представление чисел со знаком такое же, как и на числовой оси декартовых координат. -128 слева, 0 в центре и +127 справа. Если мне не верите, то загляните в limits.h.

При знаковом char условие невыполнимо, т.к. число не может одновременно быть "больше большего" и "меньше меньшего".

C этим согласен.
Тут не поспоришь. Зачем верю не верю.
Я имел в виду другое. Я хотел показать во что проецируются коды символов таблицы в зависимости от их типа.
А таблица знакогенератора обычно начинается с 0 а не с -128.
Хотя наверное можно и извратиться. Но в моём понимании правильнее плясать от печки, т.е. с 0
Да я тут ступил. Вечером в пятницу, уходя домой, забыл взять мозг. Извиняюсь за досадную ошибку.

Пусть char без знака
Пусть гипотетически код символа 'А' = 126
Пусть гипотетически код символа 'Г' = 129
условие if ((ch>'А')&&(ch<'Г')) {} гипотетически выполнимо если ch='Б'=127.

Теперь пусть char со знаком
Теперь код символа 'А' = 126
Теперь код символа 'Г' = -2
условие if ((ch>'А')&&(ch<'Г')) {} невыполнимо даже если ch='Б'=127.

Вот ради этого понимания я и затеял весь сыр-бор.

Всем спасибо!
Я для себя сделал выводы, посмотрев на код Сергея. Надо обязательно приводить тип к беззнаковому при сравнении.
Век живи век учись!