编写涉及文件的C代码时，是否应该定义_FILE_OFFSET_BITS=64？

Question

我注意到一些 C 项目编译的代码使用

_FILE_OFFSET_BITS=64

访问文件。现在，在我的系统（64 位）上，添加或删除它似乎没有多大作用 - 但也许在其他系统上确实如此。

我什么时候应该使用

_FILE_OFFSET_BITS=64

（或任何其他值）？或者，我需要检查什么以确保我实际上不需要它？

Answer 1

是的，请定义它。

在 64 位平台上使用

-D_FILE_OFFSET_BITS=64

没有任何缺点。在 32 位平台上，如果您正在做的事情可能需要在文件上查找/告知偏移量超过 2^1 的任何内容，那么您需要这个函数，或者准备使用单独的 64 位函数。

该行为不是默认行为的原因是 C 标准和 POSIX 指定

long int

用于各种函数 - 在 32 位 Unixen 上，

long int

通常最多只能保存 2³1 的值。现在，使用

-D_FILE_OFFSET_BITS=64

将保证使用

lseek

、

ftello

等的代码将继续在 32 位系统中工作，就像在 64 位系统中一样。

引用GLibc功能测试宏：

宏观：

_FILE_OFFSET_BITS

该宏确定应使用哪个文件系统接口，一个替换另一个。

_LARGEFILE64_SOURCE

使 64 位接口可用作附加接口，

_FILE_OFFSET_BITS

允许 64 位接口替换旧接口。

[...]

如果宏定义为值64，则大文件接口将替换旧接口。即，这些功能不能以不同的名称提供（因为它们是

_LARGEFILE64_SOURCE

）。相反，旧函数名称现在引用新函数，例如，对

fseeko

的调用现在确实调用

fseeko64

。

仅当系统提供处理大文件的机制时才应选择此宏。在 64 位系统上，该宏没有任何效果，因为

*64

功能与普通功能相同。

和

fseeko(3)

手册页：

在某些架构上，

off_t

和

long

都是32位类型，但用值64定义

_FILE_OFFSET_BITS

（在包含任何头文件之前）会将

off_t

变成64位类型。

Answer 2

Autoconf 为此提供了一个宏：

AC_SYS_LARGEFILE

。它通过在配置时检测

off_t

默认情况下是否已经是 64 位类型来添加所需的选项，如果不是，是否将

_FILE_OFFSET_BITS

设置为

64

将其转换为 64 位类型。它还检测另一个预处理器宏，

_LARGE_FILES

，以同样的方式，在某些非 GNU 系统上使用（根据评论是“AIX 风格的主机”）。

如果你使用autoconf，你可以直接使用这个宏。如果您不使用它，您可以重新实现相同的逻辑。

这些宏位于保留的名称空间中，供实现使用，因此最好不要在不像 GNU 那样使用它们的系统上设置它们。它们可能会对其他系统产生意想不到的影响。虽然我怀疑没有恶意实现会在定义这些宏时故意破坏，但某些实现（可能是未来的实现）可以合法地使用具有相同名称的宏，巧合的是，出于细微不同的目的。