Собственно, проблема в заголовке. Следующий код:
FILE *input = fopen(file_path, "rb");
успешно открывает файлы, но не более 2-х Гб, для которых fopen возвращает ноль.Та же проблема, если использовать open:
int input = open(file_path, O_RDONLY);
open возвращает -1.Компилирую так:
gcc -std=c99 main.cUname -a:
2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linuxgcc version 4.4.1
Уже с ног сбился, гуглил до посинения, нигде не встречал подобных тем, чтобы у кого-то такая проблема была.
В самом начале файла перед инклудами написать
#define _XOPEN_SOURCE 600
или
#define _GNU_SOURCE
>[оверквотинг удален]
>Компилирую так:
>gcc -std=c99 main.c
>
>Uname -a:
>2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
>
>gcc version 4.4.1
>
>Уже с ног сбился, гуглил до посинения, нигде не встречал подобных тем,
>чтобы у кого-то такая проблема была.-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>open возвращает -1.Есть такая штука, которая называется errno и она обычно отвечает на многие вопросы. В частности, в моём мане open(2) написано:
EFBIG pathname refers to a regular file, too large to be opened; see O_LARGEFILE above.вероятно именно это у вас происходит (вы можете убедиться в этом, вызвав, например, perror(3)), а above написано:
(POSIX.1-2001 specifies the error EOVERFLOW for this case.)O_LARGEFILEчто отвечает на все ваши вопросы. Всё это можно проделать самостоятельно.
(LFS) Allow files whose sizes cannot be represented in an off_t (but can be repre‐
sented in an off64_t) to be opened. The _LARGEFILE64_SOURCE macro must be defined
in order to obtain this definition. Setting the _FILE_OFFSET_BITS feature test
macro to 64 (rather than using O_LARGEFILE) is the preferred method of obtaining
method of accessing large files on 32-bit systems (see feature_test_macros(7)).
Спасибо всем за помощь! Помогло добавление опции -D_FILE_OFFSET_BITS=64.
Мне вот интересно, почему под FreeBSD никаких проблем с этим нет - без всяких костылей обычные open и seek работают с терабайтными файлами и 64битными смещениями. А у нас этот маразм.
>Мне вот интересно, почему под FreeBSD никаких проблем с этим нет -
>без всяких костылей обычные open и seek работают с терабайтными файлами
>и 64битными смещениями. А у нас этот маразм.int fseek(FILE *stream, long offset, int whence);
Действительно, очень интересно почему в FreeBSD это вдруг заработает ))Установка макроса говорит что ты знаешь что делаешь, и не собираешься пользоваться fseek.
>int fseek(FILE *stream, long offset, int whence);
>Действительно, очень интересно почему в FreeBSD это вдруг заработает ))
>
>Установка макроса говорит что ты знаешь что делаешь, и не собираешься пользоваться
>fseek.Я не про yблюдский stdio, с ним и так все понятно, а про системный API. Во FreeBSD off_t 64битный и костылей типа O_LARGEFILE и lseek64 просто нет, потому что не нужны.
>про системный API. Во FreeBSD off_t 64битный и костылей типа O_LARGEFILE
>и lseek64 просто нет, потому что не нужны.Ну это вы так думаете. А в linux не ломают syscall без веской причины. И программы написанные для 2.0 отлично работают и на 2.6 ядре.
>Ну это вы так думаете. А в linux не ломают syscall без
>веской причины. И программы написанные для 2.0 отлично работают и на
>2.6 ядре.А, ну да, ну да.