Как решить эту проблему совместимости с поддержкой больших файлов? - PullRequest
Новая
       33

Как решить эту проблему совместимости с поддержкой больших файлов?

0 голосов
/ 29 октября 2008

Библиотека, использующая off_t в качестве параметра для одной функции (поиск). Библиотека и приложение компилируются по-разному: у одного поддержка больших файлов отключена, у другого поддержка больших файлов. Эта ситуация приводит к странным ошибкам во время выполнения, потому что оба интерпретируют off_t по-разному. Как библиотека может проверить во время выполнения размер off_t для приложения? Или есть другое решение, чтобы, по крайней мере, пользователь получил значимую ошибку?

EDIT: библиотека (запрограммированная в c и с autoconf) уже существует, и некоторые сторонние приложения используют ее. Библиотека может быть скомпилирована с поддержкой больших файлов (по умолчанию через AC_SYS_LARGEFILE). Это мультиплатформенность, а не только Linux. Как можно обнаружить / предотвратить то, что установленные приложения будут повреждены при изменении LFS?

Ответы [ 3 ]

2 голосов
/ 29 октября 2008

Вы можете добавить API в библиотеку, чтобы вернуть sizeof (off_t), а затем проверить его у клиента. В качестве альтернативы библиотека может требовать от каждого приложения предоставления API для успешной ссылки:

library.c: 

size_t lib_get_off_t_size (void)
{
    return (sizeof(off_t));
}

client.c (init_function): 

if (lib_get_off_t_size() != sizeof(off_t) {
    printf("Oh no!\n");
    exit();
}

Если в библиотеке есть функция инициализации, вы можете поставить там проверку, но тогда клиенту придется предоставить API, чтобы получить размер его off_t, что, как правило, не так, как работают библиотеки.

1 голос
/ 30 октября 2008

В Linux, когда библиотека компилируется с включенной поддержкой больших файлов, off_t определяется как off64_t. Таким образом, если библиотека скомпилирована с поддержкой больших файлов, вы можете изменить ее интерфейс, чтобы всегда использовать off64_t вместо off_t (для этого может потребоваться _LARGEFILE64_SOURCE), и полностью избежать этой проблемы.

Вы также можете проверить, компилируется ли приложение с поддержкой больших файлов или нет (просмотрев, не определено ли _FILE_OFFSET_BITS или 32), и отказаться от компиляции (с #error), если оно компилируется неправильно. ; см. /usr/include/features.h и Макросы тестирования функций .

0 голосов
/ 30 октября 2008

Как уже говорилось ранее, библиотека не сможет узнать, как приложение (будучи клиентом для библиотеки) скомпилировано, но должен работать наоборот. Кроме того, я думаю, что вы говорите о динамическом связывании, поскольку статическое связывание, безусловно, не будет иметь разные переключатели в одно и то же время.

Подобно уже полученному ответу Эндрю Джонсона, библиотека может предоставить метод для определения, была ли она скомпилирована с поддержкой больших файлов или нет. Зная, что такие переключатели времени сборки в основном выполняются с определениями в C, это может выглядеть так: 

//in library:
BOOL isLargeFileSupport (void)
{
#ifdef LARGE_FILE_SUPPORT
    return TRUE;
#else
    return FALSE;
#endif
}

Затем приложение знает, как обрабатывать размеры файлов, сообщаемые этой библиотекой, или может отказаться работать при несовместимости: 

//in application
BOOL bLibLFS = lib_isLargeFileSupport();
BOOL bAppLFS = FALSE;
#ifdef LARGE_FILE_SUPPORT
    bAppLFS = TRUE;
#endif

if (bLibLFS != bAppLFS)
    //incompatible versions, bail out
    exit(0);
...