Отправка числа 0 (ноль) по уарту

[Someone]

Самое опасное что только может быть, это код который работает и выдаёт похожие на правильные, но неправильные результаты. С вашим имхом вы как раз на пути туда. А вот отлов переполнения как раз позволяет предотвратить это и что-то таки сделать. Что именно уже зависит от конкретной аппликухи.

Ну и? Вариант с флагом переполнения так же приведен.

То есть ваш код имеет недокументированные и неочевидные взаимосвязи. Сиречь поддерживаться в нормальных производственных условиях не может.

Как и приведенный исходный . Речь ведь изначально велась о том, что уровень авторов кодевижна не сильно высок, и код можно без особого труда улучшить, написав короче, но с тем же (почти, исключая ненужные переменные и действия с ними) функционалом, а ведь они еще денег просят за свой компилятор. (Хотя опять же, имхо кодевизарды - зло в любом компиляторе, не только кодевижене, и начинающим программистам их использовать не следует, т.к. не будет должного понимания работы устройства).

В нормальном исходном коде с нормально сделанной функцией getchar этот флаг не нужен вообще. Это ещё одна причина почему в стандарте getchar возвращает именно int а не char. Потому как иметь какой-то ещё мистический флаг означает нарываться на неприятности. Баги сиречь.

С этим я и не спорю. Но речь-то в данном случае идет о конкретном коде, выданным визардом кодевижина. И улучшать можно именно этот код именно в том виде, что он имеет. Т.е. с возвращаемым char.

Код должен для начала работать правильно, а быстрее или нет - второй вопрос.

Опять же, в данном случае, исходный код работает, не правильно, не по стандарту С. Я же показываю, что этот код можно без напряга оптимизировать, и при этом он продолжит работать почти так же, как исходный, но при этом будет и короче и быстрее.

Резюме: экзамена по программированию вы бы у меня не сдали

напишите-ка для себя формулу условия переполнения при условии неиспользования счётчика символов в кольцевом буфере.

Счетчик символов, которые можно прочитать из буфера не нужен? Условие выполнено?

[urmlr]

А как тада весь Unix работает?

У меня лично на всех серверах вообще нет ничего, кроме ascii, за ненадобностью. Кому охота иметь некую кодировку, может в KDE или Gnome поиметь UTF. Но сам компилер как таковой это не поддерживает, т.е. есть встроенный тип char, но встроенного типа wchar нету. И не будет.

[OlegNZH]

Восточные друзья стараются (умучили-не хватает им) а UTF-8 или UTF-16 - как повезёт(иногда даже смешно- пользую BitFontCreat.....- (знакогенераторы требуются-рисую) - так он - то-так,то так...все дефолты тазиком).

[urmlr]

Восточные друзья стараются (умучили-не хватает им

Нормальный юникод должен быть как минимум трёхбайтным, а если учитывать уроки истории, так и четырёх. UTF-8 вообще насмешка...

[_guardianangel]

У меня лично на всех серверах вообще нет ничего, кроме ascii, за ненадобностью.

И таки шо Вы выбираете при установке *nix - ов в качестве системной локали? Уж не дефолтное ли UTF8.ru_RU? Или месье зная толк в извращениях выбирает CP1251.ru_RU?

[urmlr]

И таки шо Вы выбираете при установке *nix - ов в качестве системной локали?

LC_ALL=C ессессно. Какой, к чёрту, "_RU"? Побойтесь того в кого вы верите

[code-by]

начали с уарта, закончили unix-ом и utf

[Cybermaker]

И никто не говорит об удвоении памяти под каждый символ, если getchar возвращает int, это совсем не значит что этот int надо в память фигачить

Уважаемый, об этом говорит спецификация на Си. В С++ чар урезан до байта.

У меня лично на всех серверах вообще нет ничего, кроме ascii, за ненадобностью.

Логично. Особенно если на серверах нет БД. Как только она появляется и требует локализации: вопрос с выбором кодировки встаёт очень остро.

Нормальный юникод должен быть как минимум трёхбайтным, а если учитывать уроки истории, так и четырёх.

Есть такое понятие как simplified [восточный язык] - именно он является используемым. Городить таблицу под 7000 иероглифов никому не надо. Хочется - нарисуй в гифе например.

начали с уарта, закончили unix-ом и utf

Просто продолжаем говорить о размерностях.