新气象气候开源库C API：size_t、unsigned long long与uint64_t选型咨询

我正在为面向气象学家和气候科学家的开源库开发一款读取GRIB2文件的新API。该库需要处理8位、16位、32位及64位的有符号与无符号整数类型。

在netcdf-c库中，我们使用unsigned long long类型：

int
nc_put_att_ulonglong(int ncid, int varid, const char *name, nc_type xtype,
                     size_t len, const unsigned long long *op);

但我们有时也会使用size_t类型：

int
nc_inq_grpname_full(int ncid, size_t *lenp, char *full_name);

尽管这个函数是我编写的，但我已记不清当时选择size_t而非unsigned long long的原因了；-)

核心问题 #

1. 在编写通用库时，是否有充分理由优先选用size_t而非unsigned long long？
2. 在开发这款新API时，我是否应该使用uint64_t类型？它似乎最适合表示数据文件中实际的64位数据。

一、优先选用size_t的理由 #

• 语义精准匹配：size_t的设计目标就是用来表示内存对象的大小、数组索引或长度，它的语义和"长度/尺寸"类参数完全契合。比如nc_inq_grpname_full中的lenp用来存储组名字符串的字节长度，用size_t能让调用者一眼理解参数的用途，比unsigned long long更具可读性。
• 平台适配性：size_t的宽度会随平台寻址能力自动调整——32位系统上为32位，64位系统上为64位，完美匹配当前平台的内存操作需求。而unsigned long long是固定64位宽度，在32位平台上处理长度参数时可能会带来不必要的类型转换开销，不符合C语言的跨平台设计惯例。
• 符合标准库惯例：C标准库中大量处理长度、尺寸的函数（如strlen、malloc、memcpy）都使用size_t作为参数类型，遵循这个规范能让你的库API更符合开发者的使用习惯，降低学习和适配成本。

二、推荐使用uint64_t表示文件中的64位数据 #

• 匹配文件格式的确定性：GRIB2文件中定义的64位整数是固定宽度的8字节数据，与平台无关。uint64_t是<stdint.h>中明确规定的固定宽度无符号64位类型，能精准对应文件中的数据格式，不会因平台差异产生类型宽度变化。
• 消除类型歧义：C标准仅规定unsigned long long的宽度不小于unsigned long，并未强制要求必须是64位（尽管绝大多数平台实现是64位）。而uint64_t的宽度是标准明确保证的，用它表示文件中的64位数据能完全避免类型宽度的不确定性，让API行为更可预测。
• 统一类型体系：你的库需要处理从8位到64位的全系列有符号/无符号整数，使用uint8_t/uint16_t/uint32_t/uint64_t这样的固定宽度类型系列，能让API的类型设计更统一、清晰，调用者可以直观地将API参数与文件中的数据类型一一对应。

内容的提问来源于stack exchange，提问作者Edward Hartnett