_fseeki64() и fseeko64(), в чем отличия?

#c #файлы

Подскажите, пожалуйста, в чем разница между функциями _fseeki64() и fseeko64()?

В данный момент занимаюсь разработкой файловой утилиты. Столкнулся проблемой, которая
заключается в том, что классические fopen(), fseek() и ftell() не умеют работать с
файлами более 2 ГБ (по крайней мере, при использовании MinGW x32), а мне именно с такими
файлами работать и нужно.

Попробовал решить проблему использованием WinAPI-шных функций: CreateFile(), GetFileSize()
и пр. Системные вызовы неудобны по ряду причин. Хотелось бы разобраться со стандартными
средствами языка, которые позволяют работать с большими файлами.

Плюс, стандартные средства все равно в своих недрах вызывают системные функции.

В общем, запутался окончательно.

Знаю про существование fgetpos() и fsetpos(), но как они пересекаются с определением
размера файла и позиционированием за позицию > 2 147 483 647, так толком и не понял.
    

Ответы

Ответ 1

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

Функция _fseeki64() специфична для Visual Studio (т.е. реализована в ран-тайм библиотеках
студии и доступна только под Windows) и портирована в Mingw как расширение. В Mingw
объявление функции имеет следующий вид:

 __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File, __int64 _Offset, int _Origin);


Функция fseeko64() реализована в библиотеке GNU Lib C (glibc), которая доступна в
Unix системах. В Mingw функция объявлена следующим образом:

int fseeko64(FILE* stream, _off64_t offset, int whence);


В доках к fseeko64() так же сказано, что для того, чтобы функция работала правильно,
файл надо открывать при помощи функции fopen64(). 

Соответственно, если вы хотите, чтобы ваш код работал под Linux (gcc) и под Windows
(gcc от Mingw), то используйте fseeko64. Если же вы пишите только под Windows и хотите
чтобы ваш код компилировался в Mingw и в MSVC - используйте _fseeki64(). Это если не
привлекать дефайны и условную компиляцию.