При использовании системного уровня IO в Linux я заметил что компилятор, распознанный O_RDONLY
и O_RDWR
флаги, но это не имело никакой подсказки вообще относительно значения O_BINARY
и O_TEXT
флаги.
Действительно ли это - вещь Linux?
Linux и почти все разновидности Unix в этом отношении не делают различий между двоичными и текстовыми файлами. Таким образом, стандартных констант с таким именем не существует. Вы можете вручную определить нулевые константы в Linux, если хотите включить их в свой код для целей переносимости.
http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2007-03/msg00147.html
Это ерунда. Операционные системы * nix не выполняют автоматическое преобразование перевода строки для ввода-вывода в «текстовых» файлах, поэтому флаги O_TEXT и O_BINARY не имеют смысла.
Windows использует \ r \ n для окончания строк, Linux (и другие Unix-подобные) используют только \ n. В Windows чтение O_BINARY дает вам необработанные данные, возможно, нечетные окончания строк и все такое, в то время как O_TEXT нормализует окончания строк, поэтому ваш код C видит только один символ.
В Linux и др. Нет смысла различать текст и двоичный код, потому что данные в любом случае имеют только один символ, поэтому флаги не нужны.
На уровне языка C и его стандартной библиотеки нет таких вещей, как O_BINARY
и O_TEXT
флаги. Двоичный или текстовый режим выбирается путем добавления спецификатора b
параметра режима функции fopen
. Сам спецификатор, конечно, поддерживается всеми реализациями C, но на платформах POSIX этот спецификатор не действует: согласно спецификации POSIX текстовый режим такой же, как и двоичный режим.
Неудивительно, что если вы углубитесь в уровень нестандартных специфичных для платформы функций ввода-вывода Unix, вы обнаружите, что они вообще ничего не знают об этом текстовом / двоичном различии.
На уровне ОС нет разницы между двоичным и текстовым файлом в Unix. Текстовый файл имеет только ограниченное содержание. Это также верно для Windows, но соглашения, используемые C для конца строк, такие же, как в Unix, в то время как Windows использует пару CR / LF (и явный маркер конца файла в некоторых контекстах, но обработка это не было согласовано даже в системных программах, когда я проверял в прошлый раз), поэтому требуется сопоставление для соблюдения соглашений, установленных C.