为什么FFTW使用ptrdiff_t而非size_t等类型定义数组尺寸参数？

疑问1：为什么使用带符号的ptrdiff_t而非表示尺寸的无符号size_t？ #

• 步长参数存在合法负值场景：虽然数组尺寸要求非负，但FFTW的guru接口支持负步长，可实现逆序访问数组、跨维度对齐等特殊操作，带符号类型天然适配这一需求，不需要额外做无符号到带符号的转换。
• 避免无符号算术陷阱：FFTW内部需要大量做维度、偏移量的算术计算，无符号类型的size_t在做减法时如果出现小值减大值，会产生不符合直觉的超大正数值，这类bug极难排查；带符号的ptrdiff_t的算术行为更符合开发者的常规预期，也更方便接口做入参合法性校验（直接判断是否小于0即可拦截非法参数）。
• 跨语言/接口兼容性更好：大量FFTW用户从Fortran、Python等外部语言调用接口，这类语言的默认整数类型均为带符号，若使用size_t会出现类型不匹配问题，甚至导致隐式类型转换引发的错误。
• fftw_malloc使用size_t是因为遵循标准库内存分配的规范，仅负责单节点本地内存块的分配，和面向计算逻辑的接口参数选型是独立设计的，不存在冲突。

疑问2：为什么MPI分布式场景不选用取值范围更大的intmax_t/uintmax_t？ #

• 主流平台ptrdiff_t的取值范围已经足够覆盖需求：当前绝大多数HPC平台采用LP64模型，ptrdiff_t为64位带符号整数，正数值上限可达2^63-1，对应单维度尺寸上限是8EB，完全可以覆盖可预见的分布式数据集规模。
• 与MPI原生接口兼容：MPI标准的分布式数据操作接口（如MPI_Type_create_subarray、分布式内存寻址相关接口）大量使用MPI_Aint类型，64位平台下MPI_Aint与ptrdiff_t完全二进制兼容，不需要额外类型转换，避免转换过程中出现溢出或精度损失。
• 兼容性与性能更优：intmax_t是C99才引入的类型，FFTW需要兼容大量仍在使用老编译器的HPC集群环境，ptrdiff_t是C89就存在的标准类型，兼容性更好；同时ptrdiff_t是平台原生字长类型，运算效率比可能跨字长的intmax_t更高。
• 分布式场景下本地块大小必然不超过单节点SIZE_MAX，单节点内存寻址不需要更大的类型，全局尺寸的ptrdiff_t上限已经足够支撑当前所有超算的业务需求，不需要额外引入更复杂的类型。

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