LINUX.ORG.RU
ФорумTalks

Об ANSI C


0

0

Сегодня пытался выполнить dmg2iso. Последний упорно выдавал ошибку открытия файла на примитивном fopen(filename, "rb").

strace показал ошибку EFBIG (File too large), чем меня поставил в тупик.

Временно решил проблему аналогичной Java утилитой, но возник вопрос: неужели на ANSI C в принципе нет способа работать с 7-гиговыми файлами на 32-битной архитектуре?

P.S. А если сделать open, а потом fdopen всё будет хорошо?

★★★★

Re: Об ANSI C

Нет

anonymous ()

Re: Об ANSI C

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

Есть.

tailgunner ★★★★★ ()
Ответ на: Re: Об ANSI C от anonymous

Re: Об ANSI C

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

Моск ?

anonymous ()
Ответ на: Re: Об ANSI C от anonymous

Re: Об ANSI C

-D_GNU_SOURCE

или

-D_LARGEFILE64_SOURCE

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

tailgunner ★★★★★ ()
Ответ на: Re: Об ANSI C от fdn

Re: Об ANSI C

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

Davidov ★★★★ ()

Re: Об ANSI C

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

anonymous ()
Ответ на: Re: Об ANSI C от anonymous

Re: Об ANSI C

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

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

Davidov ★★★★ ()
Ответ на: Re: Об ANSI C от Davidov

Re: Об ANSI C

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

tailgunner ★★★★★ ()
Ответ на: Re: Об ANSI C от gaa

Re: Об ANSI C

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Об ANSI C от tailgunner

Re: Об ANSI C

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

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

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

Davidov ★★★★ ()
Ответ на: Re: Об ANSI C от tailgunner

Re: Об ANSI C

Может Large File Specification? ;)

anonymous ()
Ответ на: Re: Об ANSI C от Davidov

Re: Об ANSI C

> То есть о 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).

tailgunner ★★★★★ ()
Ответ на: Re: Об ANSI C от Davidov

Re: Об ANSI C

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Об ANSI C от Davidov

Re: Об 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

klalafuda ★☆☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.