Об ANSI C

Нет

> неужели на ANSI C в принципе нет способа работать с 7-гиговыми файлами на 32-битной архитектуре?

Есть.

ну, так в студию его, пожалуйста!

> ну, так в студию его, пожалуйста!

Моск ?

gcc -D_FILE_OFFSET_BITS=64

-D_GNU_SOURCE

или

-D_LARGEFILE64_SOURCE

должно помочь. Конечно, не всякая программа корректно скомпилируется с этими опциями.

И тут же перестаёт работать fseek?

А fseek64 нету?

Насколько я понимаю, это уже будет не ANSI.

А вот Бёрди в соседнем топике говорит, что "64 bit - это изврат чистой воды." %)

Ну если сам Бёрдии... )

Впрочем, у меня тоже сложилось впечатление, что поддержка 64-битных архитектор сейчас приблизительно на том же уровне, что и поддержка локали UTF8 в 2005-м году.

Причем здесь 64-бит архитектуры? Речь идет о LFS, который замечательно поддерживается уже несколько лет как.

> Речь идет о LFS

А может всё же LSB?

>> Речь идет о LFS

>А может всё же LSB?

И LSB тут тоже ни при чем. И LSD - тоже.

В данном случае LFS - это Large File Supportю

Поправь меня, если я ошибаюсь.

Насколько я понимаю все проблемы в том, stdio завязан на int. То есть о LFS можно говорить на 32-битных архитектурах, на 64-битных такой проблемы вообще нет.

И, опять же, насколько я понимаю, в ANSI C fseek принимает int. То есть программы написанные в соответствии с этим стандартом в общем случае не могут поддерживать длинные файлы на 32-битных архитектурах. Да, есть fseeko, но это (пока?) не входит в стандарт, насколько я понимаю.

Может Large File Specification? ;)

Тут всё расписано: http://www.unix.org/version2/whatsnew/lfs20mar.html

> То есть о LFS можно говорить на 32-битных архитектурах, на 64-битных такой проблемы вообще нет.

Да

> И, опять же, насколько я понимаю, в ANSI C fseek принимает int

Почти (long, на самом деле).

> То есть программы написанные в соответствии с этим стандартом в общем случае не могут поддерживать длинные файлы на 32-битных архитектурах.

Нет. При особых -D, указанных при компиляции, вызовы вроде open/read/wrtite/lseek подменяются на open64/read64/wrtite64/lseek64. Входят ли эти функции в POSIX, я не помню, но исходный код в любом случае остается POSIX-compliant.

Кстати, если верить info libc, fseeko - это SUSv2 (подменяется на fseeko64).

Но ведь ANSI C и POSIX совершенно разные стандарты.

open - это POSIX, а fopen - это ANSI C.

> Но ведь ANSI C и POSIX совершенно разные стандарты.

Разве вся библиотека ANSI C не является частью POSIX?

> open - это POSIX, а fopen - это ANSI C.

Подменяется и то, и другое

> Насколько я понимаю все проблемы в том, stdio завязан на int. То есть о LFS можно говорить на 32-битных архитектурах, на 64-битных такой проблемы вообще нет.

не совсем. стандартные fseek()/ftell() действительно завязаны на конкретном типе - long - но есть и расширения в виде fseeko()/ftello(), которые уже оперируют off_t и, как следствие, если off_t определен как long long то проблема снимается.

http://www.opengroup.org/onlinepubs/009695399/functions/fseek.html
http://www.opengroup.org/onlinepubs/009695399/functions/ftell.html

// wbr