LINUX.ORG.RU

Интересно где sizeof(char) == sizeof(int)

 ,


1

3

https://en.wikibooks.org/wiki/C_Programming/stdio.h

Разбирается в викиучебнике (емнип, вроде вообще из K&R взято, но под рукой его нет) ввод/вывод из файла и отмечается, что просто проверки на EOF может оказаться не достаточно в таких ситуациях

On systems where int and char are the same size (i.e., systems incompatible with minimally the POSIX and C99 standards), even the «good» example will suffer from the indistinguishability of EOF and some character's value. The proper way to handle this situation is to check feof and ferror after getchar returns EOF. If feof indicates that end-of-file has not been reached, and ferror indicates that no errors have occurred, then the EOF returned by getchar can be assumed to represent an actual character. These extra checks are rarely done, because most programmers assume that their code will never need to run on one of these «big char» systems. Another way is to use a compile-time assertion to make sure that UINT_MAX > UCHAR_MAX, which at least prevents a program with such an assumption from compiling in such a system.

Стало интересно, где такое вообще бывает? Это рудимент из 70-х (тоже интересно, где было) или на каких-то системах всё же такое возможно. Вообще есть хотя бы небольшой смысл в совремённых программах закладываться на подобное или можно смело игнорировать. Мне кажется, что можно игнорировать, но все же, вдруг например в embedded такое реально встречается или в каких-то ОС, не самых неизвестных.

★★★★★

Последнее исправление: anonymous_incognito (всего исправлений: 2)
Ответ на: комментарий от beastie

Там немного другой вопрос, просто про длину char.

Но любопытно, получается, что хотя sizeof(char) всегда равен 1, но в принципе число бит в байте не всегда 8. Если исключить совсем древнюю экзотику, то может быть актуально, что

Some models of Analog Devices 32-bit SHARC DSP have CHAR_BIT=32, and Texas Instruments DSP from TMS32F28xx have CHAR_BIT=16,

Там ещё https://www.thecodingforums.com/threads/implementations-with-char_bit-32.4400...

Just a reminder that CHAR_BIT == 32 and sizeof(int) == 1 both being true doesn't automatically imply either that INT_MAX == CHAR_MAX or that INT_MIN == CHAR_MIN. In particular,

INT_MAX 2147483647 CHAR_MAX 1073741823 INT_MIN -2147483648 CHAR_MIN -1073741824

are allowed, or even

INT_MAX 2147483647 CHAR_MAX 127 INT_MIN -2147483648 CHAR_MIN -128

are allowed.

What I would expect in a hosted implementation with CHAR_BIT == 32 and sizeof(int) == 1 is

INT_MAX 2147483647 CHAR_MAX 2147483647 INT_MIN -2147483648 CHAR_MIN -2147483647

So EOF could be -2147483648 and there would be no conflict with any character value. Of course, on such a system, outputting binary data would most likely be done with unsigned char rather than char.

Никогда ничего не писал для них и для DSP вообще, но получается, если верить автору поста, что даже на таких экзотических системах всё же EOF не конфликтует с значением char.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Не факт что на таких платформах он будет.

invy ★★★★★
()

В серии TMS320 (по крайней мере в c54 и c55, под которые я когда-то писал) char 16 бит. Более того, если мне не изменяет память, в c54 вообще нет команд работы с байтами.

Puzan ★★★★★
()
Последнее исправление: Puzan (всего исправлений: 1)
Ответ на: комментарий от Puzan

Ага, по ссылке выше есть про другие TMS, тоже 16 бит, а у Analog Devices 32 бита. Но как я понял, всё же конфликта с EOF не происходит, хотя конечно, привыкшего к условностям x86 может ждать немало сюрпризов.

anonymous_incognito ★★★★★
() автор топика

TI TMS320C55x. Сам страдаю. Адресовать 8-бит «байт» напрямую невозможно. Только через 16-бит.

Причём C5517 анонсирован совсем недавно, в 2014-ом.

gag ★★★★★
()
Ответ на: комментарий от anonymous_incognito

Не помню, чтобы приходилось уделять внимание этому граничному случаю. Но, вообще, это известная проблема, которая вместе с решением описана тут: SEI CERT C Coding Standard. FIO34-C. Distinguish between characters read from a file and EOF or WEOF

gag ★★★★★
()

Мне кажется, что можно игнорировать, но все же, вдруг например в embedded такое реально встречается

Вот и другие игнорируют, даже в open-source embedded. За исключением кое-каких коммерческих фирм.

gag ★★★★★
()
Ответ на: комментарий от Puzan

И шо, при чтении файлов читаются по 2 реальных байта? Или таки байты читаются нормально, просто половина регистра не используется? Или там вообще файлов нет?

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

просто половина регистра не используется?

Ага. Данные в char занимают в два раза больше памяти чем необходимо. Для обмена приходится их перепаковывать.

Или там вообще файлов нет?

Я пользовался эмуляцией CIO через JTAG. Т.е. файлы были на ПК. Но для FAT/SD-Card, наверняка, тоже есть реализация соответствующих функций.

gag ★★★★★
()
Ответ на: комментарий от Legioner

И шо, при чтении файлов читаются по 2 реальных байта?

Ну контроллер SD карты читает побайтно конечно, но складывает в регистры, к которым процессор может обращаться только с 16-ти битным выравниванием. Если прочитаешь один байт, то будет 0x00XX, а если два, то 0xYYXX. Как-то так.

Puzan ★★★★★
()

Для такого устройства твой код все равно не подойдет, т.к. будет слишком большим и медленным, так что не парься

annulen ★★★★★
()

Сразу приходят на ум 8битные системы. Например - pic. Я на C правда их не трогал, что бы хомячка не разорвало, а чего там было на асме - хоть убей уже не вспомню. Тем не менее C компилятор там был, и, кажется даже регистры были, или банки.

pon4ik ★★★★★
()

Это кстати забавный факт, который можно использовать помимо дефайнов для проверки чем собирается, плюсами или с:

sizeof('a') == sizeof(int), или ты про это и спрашиваешь?

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Не про это, а так получилось, что закопался в работу с файлами. Казалось бы в простых ситуациях давно тут всё известно и чуть ли не на автомате пишется, но «век живи - век учись», есть некоторые тонкости.

anonymous_incognito ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.