Смысл EOF в си

[TheRuinedMap]

Vladimir-80 в сообщении #1537616 писал(а):

Что такого эдакого может быть при реализации if (a-b)...? Если a и b равны, их разность всегда будет равна 0 - в электрическом его представлении.

Что это вы такое несете? Какое это имеет отношение к рассматриваемой теме? Никто вам здесь не предлагал заменять арифметический ноль на именованную константу.

Vladimir-80 в сообщении #1537616 писал(а):

Если мы договорились последним байтом файла ставить -1, то при корректном формате файла в его конце -1 и будет.

Что это вы такое несете? Не существует никакого "последнего байта в файле", в котором мы якобы "договаривались ставить -1". О чем вы? O_o

Не существует никакого "байта EOF". Значение EOF - это просто код завершения функции. Ни к каким "байтам в файле" он не имеет никакого отношения. И даже если у вас на руках есть некий экзотический носитель, который отмечает конец файла неким "байтом" с зарезервированным значением, значение этого байта никак не будет связано со значением кода возврата EOF. Скорее всего этот байт в файле будет содержать классическое 0x1A.

Vladimir-80 в сообщении #1537616 писал(а):

Я злой и страшный серый волк противник всяческих излишеств и украшательств, я за чистоту помыслов и прозрачность поступков...

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

Vladimir-80 в сообщении #1537616 писал(а):

TheRuinedMap в сообщении #1537614 писал(а):

А там уже не будет никакого "нуля" на месте нулевых указателей

Нулевой указатель, кстати, тоже весьма сомнительная концепция. Он ничем не лучше просто неинициализированного указателя. Ни тем, ни другим пользоваться нельзя ведь.

Что это вы такое несете? Народ, это тролль?

[Vladimir-80]

TheRuinedMap в сообщении #1537619 писал(а):

Никто вам здесь не предлагал заменять арифметический ноль на именованную константу.

Не арифметический ноль, а логическое FALSE внутри скобок функции if(). Которое всё равно есть ноль.

TheRuinedMap в сообщении #1537619 писал(а):

Не существует никакого "последнего байта в файле", в котором мы якобы "договаривались ставить -1". О чем вы? O_o

А что же такое получает та же функция getc(), дойдя до конца файла? Это ведь работает и без единого упоминания EOF в программе.

TheRuinedMap в сообщении #1537619 писал(а):

это тролль?

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

-- 03.11.2021, 20:47 --

TheRuinedMap в сообщении #1537619 писал(а):

Не существует никакого "байта EOF". Значение EOF - это просто код завершения функции.

Пусть это не содержимое файла. Это значение, которое ОС посылает программе по достижению конца файла, насколько я понимаю. Но ведь это же заранее согласовано, так? Так зачем заменять простое на сложное?

[TheRuinedMap]

Vladimir-80 в сообщении #1537621 писал(а):

Не арифметический ноль, а логическое FALSE внутри скобок функции if().

Во-первых, FALSE - это что-то из WinAPI. К чему это тут - мне не ясно. Во-вторых, явное сравнение логических значений с true или false - странная практика, которая практически не имеет хождения в реальной жизни. В-третьих, результат a-b - арифметическое, а не логическое значение. Никому и нигде и в голову не придет сравнивать его с FALSE.

О чем вы?

Vladimir-80 в сообщении #1537621 писал(а):

А что же такое получает та же функция getc(), дойдя до конца файла? Это ведь работает и без единого упоминания EOF в программе.

Ничего не получает, разумеется.

Если функция getc пытается прочитать что-то, когда файл уже закончился, то попытка чтения завершается безуспешно. В такой ситуации getc возвращает вам значение EOF.

В типичной POSIX реализации: функция getc изнутри вызывает функцию read, прося ее прочитать 1 байт. А функция read в ответ возвращает 0, мол "я смогла прочитать 0 байтов". Вот, увидев этот 0, функция getc возвращает вам значение EOF. Все очень просто.

Я уже разжевывал это выше, в сообщении про то, как работает Ctrl-D.

Vladimir-80 в сообщении #1537621 писал(а):

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

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

[Vladimir-80]

TheRuinedMap в сообщении #1537622 писал(а):

В такой ситуации getc возвращает вам значение EOF.

Функция запрашивает данные у операционной системы, операционная система ей заранее условленным образом сообщает, что всё имевшееся уже закончилось, и далее ничего нет, там чужое лежит. Обычно такое сообщение имеет форму -1. Так?

-- 03.11.2021, 21:03 --

TheRuinedMap в сообщении #1537622 писал(а):

Во-первых, FALSE - это что-то из WinAPI. К чему это тут - мне не ясно.

Да всё к тому же: что FALSE, что false, что true, что NULL, что EOF - все эти ярлыки имеют за собой обычные числа. И совершенно непонятно, зачем вводить всю эту мишуру в процесс...

[TheRuinedMap]

Vladimir-80 в сообщении #1537624 писал(а):

TheRuinedMap в сообщении #1537622 писал(а):

В такой ситуации getc возвращает вам значение EOF.

Функция запрашивает данные у операционной системы, операционная система ей заранее условленным образом сообщает, что всё имевшееся уже закончилось, и далее ничего нет,

Верно.

Vladimir-80 в сообщении #1537624 писал(а):

Обычно такое сообщение имеет форму -1. Так?

Нет. Ответ операционной системы функции getc ни чего не знает ни о каком -1. Как оформлен ответ операционной системы функции getc - зависит от операционной системы. Как я уже несколько раз написал выше, в соглашениях POSIX "конец файла" обозначается как "функция read() вернула 0".

А EOF - это ответ функции getc вам. Константа EOF существует только между вами и стандартной библиотекой языка С. "Операционная система" ничего про EOF не знает. Фактическое значение EOF (-1 это или что-то другое) не имеет никакой физической привязки ни к чему: ни к операционной системе, ни к хранимым в файлам данных.

[Vladimir-80]

Сколько же слоёв там задействовано. Надо бы во всех разобраться. Ну или переключиться на микроконтроллеры - там вроде бы попроще всё устроено :)

TheRuinedMap в сообщении #1537625 писал(а):

"функция read() вернула 0"

Кстати, а что это за функция? Не в смысле содержания, это понятно, а в смысле какого (псевдо?)языка, откуда она вообще, о чём в данном случае речь?

[TheRuinedMap]

Vladimir-80 в сообщении #1537624 писал(а):

Да всё к тому же: что FALSE, что false, что true, что NULL, что EOF - все эти ярлыки имеют за собой обычные числа. И совершенно непонятно, зачем вводить всю эту мишуру в процесс...

Снова сваливание всего в одну кучу, основанное на незнании матчасти. В том то и дело, что число 0, использованное в указательном контексте - это не обычное число. NULL как раз подчеркивает эту необычность. То же самое можно сказать и об остальных.

Внимание, вопрос

Используется синтаксис C++

struct S;

int main()
{
  int S::*p = 0;
}
 

Какое число будет физически занесено в ячейку памяти p в странслированном коде в типичных современных реализациях?

-- 03.11.2021, 10:19 --

Vladimir-80 в сообщении #1537626 писал(а):

TheRuinedMap в сообщении #1537625 писал(а):

"функция read() вернула 0"

Кстати, а что это за функция? Не в смысле содержания, это понятно, а в смысле какого (псевдо?)языка, откуда она вообще, о чём в данном случае речь?

https://man7.org/linux/man-pages/man2/read.2.html

Функции read() и write() - классические функции стандарта POSIX, через которые проходит ввод-вывод в операционных системах группы *nix.

[Vladimir-80]

Я с плюсами не работал, мне чистый си ближе. Но предположу, что будет занесён ноль.

-- 03.11.2021, 21:26 --

TheRuinedMap в сообщении #1537627 писал(а):

ввод-вывод в операционных системах группы *nix

Хмм... Инструмент уровня операционки, получается. От языка, на котором условный я пишу программу, эта функция не зависит, так? Интересно. Но если есть read(), то зачем нужны всякие getc()?
Впрочем, не отвечайте, а то я уведу тему сильно в сторону своим любопытством.

[EUgeneUS]

TheRuinedMap в сообщении #1537513 писал(а):

Комбинация Ctrl-D в POSIX системах сама по себе не имеет никакого отношения к EOF и не является символом EOF.

Комбинация Ctrl-D - это все лишь команда терминала, которая заставляет терминал протолкнуть накопленный на этот момент буфер ввода во входной поток ожидающего этого ввода процесса. Ожидающий ввода процесс ожидает завершения функции read() на входном потоке. Комбинация Ctrl-D всего лишь вызывает досрочное завершение функции read(). Функция read() при этом возвращает количество байтов, которое она успела прочитать до момента нажатия Ctrl-D. В этом и заключается вся суть комбинации Ctrl-D - вызвать досрочное завершение функции read(). Больше ничего. Ни о каком EOF комбинация Ctrl-D не знает и никакого отношения к EOF не имеет.

Вообще-то, при нажатии комбинации Ctrl-D терминал таки пошлет символ

0x04

(EOT, end of transmission).
А всё, что написано в цитате произойдет в "подсистеме TTY", а именно в дисциплине линии (если мне память не изменяет) при обработке этого символа.

[TheRuinedMap]

Vladimir-80 в сообщении #1537628 писал(а):

Но если есть read(), то зачем нужны всякие getc()?

Не понимаю вопроса. getc() - функция стандартной библиотеки языка С. read() - функция POSIX, к стандартной библиотеке языка С никакого отношения не имеющая. Отсюда уже должно быть очевидно, зачем нужна getc().

-- 03.11.2021, 11:41 --

Vladimir-80 в сообщении #1537628 писал(а):

Но предположу, что будет занесён ноль.

В переменную физически будет занесено 0xFF...F, то есть фактически -1. И сравнение if (p == 0) будет странслировано в сравнение p с 0xFF...F. В большинстве традиционных С++ реализацией (MSVC, GCC, Clang) нулевой указатель типа указатель-на-поле физически представляется как 0xFF...F, потому что физическое значение 0 в таких указателях уже "занято" для других целей.

Константа 0, используемая в указательном контексте совсем не обязательно превращается в 0 в машинном коде. 0, который вы пишете в исходном тексте свой программы - это в общем случае лишь символ в тексте, похожий на бублик. Прямого отношения к тому, что из него получится в "железе" он не имеет.

Vladimir-80 в сообщении #1537628 писал(а):

Я с плюсами не работал, мне чистый си ближе.

В С ситуация такая же, просто примеры найти труднее. Во фреймворках вроде CUDA как раз есть null-указатели, которые физически не являются нулевыми, хоть это и не стандартный С.

-- 03.11.2021, 11:47 --

EUgeneUS в сообщении #1537632 писал(а):

Вообще-то, при нажатии комбинации Ctrl-D терминал таки пошлет символ

0x04

(EOT, end of transmission).

Ну это вопрос того, где вы проведете срез. Разумеется, в этом flow существует точки, в которых Ctrl-D еще ничем не отличается от других комбинаций клавиш, и существуют точки, где от Ctrl-D уже не осталось и следа.

Я лишь хотел заметить, что комбинация Ctrl-D не записывает в stdin некий "волшебный" символ, который будет расценен, как маркер конца файла. Комбинация Ctrl-D перехватывается намного раньше, обрабатывается совсем по-другому и к "концу файла" прямого отношения не имеет. Возможность использовать Ctrl-D для создания ситуации "конец файла" - это лишь побочный эффект ее основной функциональности.

[Vladimir-80]

TheRuinedMap в сообщении #1537635 писал(а):

Не понимаю вопроса.

Что read(), что getc()- всего лишь более-менее удобные способы попросить процессор сделать то, что нам нужно. Прямой способ озадачить процессор - опкоды. Но они немногословны и при этом трудны для восприятия неподготовленным глазом. Из-за этого люди придумали разного уровня языки программирования. С присущими им преимуществами и недостатками. И в мире этих языков что getc(), что read() выглядят одинаково просто читаемыми и понимаемыми, хотя относятся при этом (вроде бы) к разным уровням абстракции (мир прикладной программы и мир ОС соответственно). Так зачем изобретать человекочитаемую getc(), когда уже есть точно так же понятная read()? (Хотя последняя скорее всего так же написана на Си...)

[Dmitriy40]

Vladimir-80 в сообщении #1537638 писал(а):

Так зачем изобретать человекочитаемую getc(), когда уже есть точно так же понятная read()? (Хотя последняя скорее всего так же написана на Си...)

Пользоваться getc() гораздо проще чем read(). А read() существенно более сложная и разнообразная функция: может прочитать не только один байт, но и любое количество байтов.
Ну и на чём написана read() не имеет вообще никакого отношения к делу. Хоть на лиспе.

Vladimir-80 в сообщении #1537621 писал(а):

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

Значит для Вас открыты все те дороги с тучей раскиданных граблей, по которым мир уже прошёл, налетел, подумал и исправил. А у Вас всё впереди!
Именованные константы придуманы именно для облегчения жизни программисту, особенно не при первом написании кода, а при его поддержке и модификации, когда человек уже давно забыл где просто число 0, где это результат разности двух одинаковых чисел, где нулевой указатель, а где смещение в структуре. И чтобы изменить смещение в структуре не испортив всю программу придётся заново разбираться где в каком смысле использован символ 0. А с именованными константами достаточно просто изменить значение одной из них, вообще не смотря в основной текст программы. Это азы вообще-то.

Ну и про ассемблер скажу, как человек плотно на нём пишущий. Да, при желании можно получить очень хорошую производительность и размер программы. Только Вы забыли про цену этого: время и усилия по написанию программы. И по сопровождению. А производительность нужна вовсе не всегда и не везде, с тем же getchar() она 100% не нужна. То что Вы будете писать на ассемблере год (не забываем про разную аппаратуру у клиентов!), другой человек напишет на С за неделю. Догадайтесь кто получит следующий заказ и больше заработает.
Оптимальной считается тактика писать всё на С и потом лишь самые внутренние вычислительные циклы при необходимости переписывать на ассемблере. Писать на ассемблере всё — извращение (писал, знаю). Для компьютеров компиляторы ЯВУ достаточно хороши и улучшить их код без глубокого знания внутренностей процессора весьма сложно (а новичок скорее испортит код чем улучшит).
С МК ситуация та же: для всех есть как минимум С, а часто и много других ЯВУ, на асме пишут лишь извращенцы (вроде меня) или лишь небольшие кусочки самого нагруженного кода (типичный пример — обработчики прерываний). Ну или когда размер исполняемого кода критичен (по цене МК), но тогда почти всегда программа достаточно проста (сотни-тысячи строк, не более, дальше уже проще на С десятки-сотни строк написать, да, в десятки и более раз меньше).
Вы похоже даже не пытались писать на асме ничего серьёзнее десятка команд, а то бы знали что например в WinAPI, которым легко пользоваться из асма, есть аналог printf(), но нет аналога scanf() и писать синтаксический разбор входных текстовых строк и параметров командной строки вам придётся самому. А корректный разбор, на асме напомню, с обработкой возможных ошибок ... Это совсем не десяток и не сотня строк! Всего лишь на чисто служебное действие, ещё даже не основной код программы. Я вот до сих пор (больше десятка лет) ленюсь и потому мои программы на асме снаружи практически никак не управляются, каждый раз приходится менять исходный код и перекомпилировать. Потому что когда надо такую обработку, то речь о производительности уже не идёт и вполне можно пользоваться ЯВУ, а нагруженный асм код убрать в dll и спокойно его оттуда вызывать из любого языка.

Короче, если не хотите годами ходить по уже изученным граблям — интересуйтесь мировым опытом. И следуйте ему. А не стройте из себя нигилиста.

[Emergency]

Vladimir-80 в сообщении #1537621 писал(а):

Так зачем заменять простое на сложное?

Для людей в этом есть большой смысл, а для машины - нет.
Представьте себе, что мы бы так и не догадались заменять в интернете адреса сайтов на слова и фразы... Тогда у каждого пользователя интернета была бы своя DNS в виде блокнота (или талмуда) со списком сайтов и их адресами.
Кстати, налоговые мазохисты так и не догадались заменять числа словами, из-за чего платежки пестрят кучей невразумительных чисел типа КБК, ОКПО, ОКОНХ... и еще десятка. А может они вовсе и не мазохисты, а садисты?