У меня есть вопрос о библиотеке Data.ByteString.Lazy.Char8 в библиотеке bytestring. В частности, мой вопрос касается функции readFile, которая документируется следующим образом:
Прочитайте весь файл лениво в ByteString. Используйте "текстовый режим" в Windows для интерпретации новых строк
Меня интересует утверждение, что эта функция будет "использовать текстовый режим в Windows для интерпретации новых строк". Исходный код для функции выглядит следующим образом:
-- | Read an entire file /lazily/ into a 'ByteString'. Use 'text mode'
-- on Windows to interpret newlines
readFile :: FilePath -> IO ByteString
readFile f = openFile f ReadMode >>= hGetContents
и мы видим, что в некотором смысле претензия в документации совершенно верна: была использована функция openFile
(в отличие от openBinaryFile
), и поэтому для файла будет включено преобразование новой строки.
Но файл будет передан hGetContents. Это вызовет Data.ByteString.hGetNonBlocking
(см. Исходный код здесь и здесь), который должен быть неблокирующей версией Data.ByteString.hGet
(см. документацию); и (наконец) Data.ByteString.hGet
вызывает GHC.IO.Handle.hGetBuf
(см. документация или исходный код). Эта функция документация говорит, что
hGetBuf игнорирует все, что TextEncoding использует в настоящее время Handle, и считывает байты непосредственно из базового устройства ввода-вывода.
который говорит о том, что факт, что мы открыли файл с использованием readFile
, а не readBinaryFile
, не имеет значения: данные будут считаны без преобразования строк новой строки, несмотря на претензии в документации, упомянутой в начале вопроса.
Итак, суть вопроса: 1. Я что-то пропустил? Есть ли смысл в том, что утверждение, что Data.ByteString.Lazy.Char8.readFile использует текстовый режим для Windows для интерпретации новых строк, является истинным? Или документация просто вводит в заблуждение?
P.S. Тестирование также указывает на то, что эта функция, по крайней мере, когда она используется наивно, когда я ее использую, не делает преобразование новой строки в Windows.