# 哎，看来在标准 C 中根本无法可移植地检查字符串转浮点数的错误 # oh, apparently it's not possible to portably check for string-to-float conversion errors in standard c **日期 / Date:** 2026-10-09 **原文链接 / Original URL:** [https://sebsite.pw/w/20261009-strtod.html](https://sebsite.pw/w/20261009-strtod.html) --- 这篇算是上一篇博客（探讨 `math_errhandling` 宏，以及 glibc 和 musl 这两个主流 C 运行库如何处理数学错误和 C 语言标准的具体规定）的续篇。 > *This is kinda a sequel-ish to my previous post, in which i go over the `math_errhandling` macro, and how math error handling is done in glibc and musl (as well as how it's specified in the standard).* 简单回顾一下背景：`math_errhandling` 是自 C99 起在 `` 中引入的一个宏，用于指示当前环境支持哪些数学错误处理机制——是传统的 `errno`（即 `MATH_ERRNO`），还是 IEEE-754 浮点异常（即 `` 中的 `MATH_ERREXCEPT`），或者两者兼具。 > *To summarize: `math_errhandling` is a macro which indicates which error-handling mechanisms are supported by `math.h` functions: `errno` (`MATH_ERRNO`) and/or floating-point exceptions (`MATH_ERREXCEPT`).* 上一篇文章中我漏掉了一点：有一族函数虽然定义在 `` 中，**并不在** `` 内部，却同样受到 `math_errhandling` 机制的直接影响——那就是字符串转浮点数系列函数：`strtod`、`strtof`、`strtold`，以及 C23 引入的固定宽度浮点函数 `strtod32`、`strtod64` 和 `strtod128`。 > *There's one thing i didn't mention in my previous post: there's one family of functions which is affected by `math_errhandling` but which isn't in `math.h`: the string to float conversion functions `strtod`, `strtof`, `strtold`, `strtod32`, `strtod64`, and `strtod128`:* 在最新的 ISO C 标准（ISO/IEC 9899:2024 / C23）第 7.25.2.6 节第 12 段中写道： > *`7.25.2.6p12`:* > > > If the correct value overflows and default rounding is in effect (7.12.2), plus or minus `HUGE_VAL`, `HUGE_VALF`, or `HUGE_VALL` is returned (according to the return type and sign of the value); if the integer expression `math_errhandling & MATH_ERRNO` is nonzero, the integer expression `errno` acquires the value of `ERANGE`; if the integer expression `math_errhandling & MATH_ERREXCEPT` is nonzero, the "overflow" floating-point exception is raised. > > > > If the result underflows (7.12.2), the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; if the integer expression `math_errhandling & MATH_ERRNO` is nonzero, whether `errno` acquires the value `ERANGE` is implementation-defined; if the integer expression `math_errhandling & MATH_ERREXCEPT` is nonzero, whether the "underflow" floating-point exception is raised is implementation-defined. > > **中文翻译：** > 若正确值发生溢出（overflow）且当前采用默认舍入模式（7.12.2），函数根据返回类型与符号返回正或负的 `HUGE_VAL`、`HUGE_VALF` 或 `HUGE_VALL`；如果整型表达式 `math_errhandling & MATH_ERRNO` 非零，则整型表达式 `errno` 获得值 `ERANGE`；如果整型表达式 `math_errhandling & MATH_ERREXCEPT` 非零，则触发“overflow（溢出）”浮点异常。 > > 若结果发生下溢（underflow）（7.12.2），函数返回一个绝对值不大于该返回类型中最小正正规数（normalized positive number）的值；如果整型表达式 `math_errhandling & MATH_ERRNO` 非零，`errno` 是否被设为 `ERANGE` 由实现定义（implementation-defined）；如果整型表达式 `math_errhandling & MATH_ERREXCEPT` 非零，是否触发“underflow（下溢）”浮点异常同样由实现定义。在 Linux 下的手册页（man page）中，关于这些函数对此机制的依赖**完全只字未提**。这其实有历史和标准分歧的原因，我稍后会细说。但 ISO C 标准明确传达的意思是：如果某个 C 标准库实现（比如轻量级 C 库 musl）在 `math_errhandling` 中没有开启对 `errno` 的支持，那么当字符串转浮点数出错时，**它根本不会设置 `errno`**！更夸张的是，一旦发生结果下溢，标准甚至**根本不强制要求该函数向调用方报告任何错误**。 > *The linux man pages for these functions literally don't mention this at all, and there actually is a reason why which i'll get to in a sec, but what the standard is saying is, if `math_errhandling` doesn't advertise support for `errno` (as is the case on musl, for instance), the string to float conversion functions **don't set `errno` on error**. furthermore, if the result underflows, the function **isn't required to report an error at all**.* 请务必注意：仅仅依靠返回值是无法判定是否发生错误的。因为当解析到一个合法的极大值或者真实溢出时，返回值可能同样都是 `±HUGE_VAL`；解析到 `0` 或者下溢时返回值都可以是 `0.0`。因此，为了检测溢出，你**必须**依赖这两种错误处理机制之一。 > *Keep in mind that the return value alone isn't enough to determine if an error occurred, so to test for overflow, you need to use one of the two error handling mechanisms.* 这里是我尝试编写的一段符合标准（standards-blessed）的代码，试图在标准 C 下以跨平台的方式捕获字符串转浮点数时的溢出或下溢错误： > *Here is my attempt at a standards-blessed way of portably checking for overflow/underflow errors in the string to float functions:* ```c #pragma STDC FENV_ACCESS ON // 提示编译器开启浮点环境访问（避免编译器优化调整异常顺序） feclearexcept(FE_OVERFLOW | FE_UNDERFLOW); errno = 0; double x = strtod(s, nullptr); bool errored = math_errhandling & MATH_ERRNO ? errno == ERANGE : fetestexcept(FE_OVERFLOW | FE_UNDERFLOW); ``` 请注意，即便是这段代码，也**无法百分之百保证**能检测到下溢错误，因为在 ISO C 标准中，报告下溢完全属于实现定义的自选动作。 > *Note that this still doesn't guarantee that underflow is detected, since reporting underflow is entirely optional for the implementation.* 你之前很可能从未见过这种写法，Linux 手册页也对此避而不谈，其根本原因在于 POSIX 标准（IEEE Std 1003.1）对这些函数的行为做出了完全不同的强制规范： > *The reason you've never done this ever (and the reason the man pages don't mention this) is that posix specifies the functions differently:* > If the correct value is outside the range of representable values, ±HUGE_VAL, ±HUGE_VALF, or ±HUGE_VALL shall be returned (according to the sign of the value), and `errno` shall be set to `[ERANGE]`. > > If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and `errno` set to `[ERANGE]`. > > **中文翻译：** > 若正确值超出可表示值的范围，应返回 ±HUGE_VAL、±HUGE_VALF 或 ±HUGE_VALL（取决于值的符号），且**必须**将 `errno` 设置为 `[ERANGE]`。 > > 若正确值将导致下溢，应返回一个绝对值不大于该返回类型中最小正正规数的值，且**必须**将 `errno` 设置为 `[ERANGE]`。可以看到，POSIX 根本不在乎 `math_errhandling` 的取值；只要发生溢出或下溢，它就强制要求库实现必须设置 `errno = ERANGE`。尽管 POSIX 在许多系统接口上比 ISO C 标准施加更严格的约束属于家常便饭，但在 Linux 的手册页（无论是描述标准库函数的 `strtod(3)` 还是 POSIX 规范手册 `strtod(3p)`）中，居然完全没有注明这是针对 ISO C 的扩展与偏差，这十分耐人寻味。 > *So posix doesn't give a shit about `math_errhandling`; it always requires the implementation to set `errno` if overflow or underflow occurs. while it's not uncommon for posix to specify stricter requirements on functions than standard c, the fact that the man page never makes any note of this being an extension (neither `strtod(3)` nor the posix specification `strtod(3p)`) is really notable to me.* 至于 POSIX 的这种硬性要求是否与标准 C 兼容……答案是非常模糊的。至少在 `` 里的数学函数中，无论 `math_errhandling` 如何取值，标准允许库设置 `errno`： > *Whether or not posix's behavior is even compatible with standard c is... unclear. at least for `math.h` functions, setting `errno` regardless of the value of `math_errhandling` is permitted:* > `7.12.2p8`: > > > If a domain, pole, or range error occurs and the integer expression `math_errhandling & MATH_ERRNO` is zero, then `errno` shall either be set to the value corresponding to the error or left unmodified. > > **中文翻译：** > 若发生定义域错误（domain error）、极点错误（pole error）或范围错误（range error），且整型表达式 `math_errhandling & MATH_ERRNO` 为零，则 `errno` 应被设置为对应错误的值，或保持不变。但在更前面的部分，标准在规范 ``（第 7.5 节第 3 段）时却有这样一句规定： > *But earlier on, when specifying `errno.h`, the standard says this:* > `7.5p3`: > > > [...] The value of `errno` may be set to nonzero by a library function call whether or not there is an error, provided the use of `errno` is not documented in the description of the function in this document. > > **中文翻译：** > […] 只要在本标准对该函数的说明中未提及对 `errno` 的使用，库函数调用便可以将 `errno` 的值设置为非零，无论是否发生错误。然而在 `strtod` 这族函数的描述中，对 `errno` 的使用**是白纸黑字写明了的**（即上文引用的 7.25.2.6p12），且该说明完全没有允许在 `math_errhandling & MATH_ERRNO` 为 0 时设置 `errno`。这从严格标准的角度看，意味着 POSIX 这种强制设置 `errno` 的行为可能违反了 ISO C 的一致性（conformance）要求。 > *`errno` is documented in the description for these functions, and that description makes no mention of setting `errno` when `math_errhandling & MATH_ERRNO` is zero. so that suggests that posix's behavior is non-conformant.* 但这还没完！到目前为止我们讨论的还仅仅是数值溢出和下溢。如果传入的字符串格式完全错误、根本无法解析成数字呢？ISO C 标准压根没把这当成一个错误状态： > *But hang on! everything i've talked about so far is only for overflow and underflow. but if the string is malformed and can't be parsed as a number, then the standard doesn't specify any error at all:* > `7.25.2.6p11`: > > > The functions return the converted value, if any. If no conversion could be performed, positive or unsigned zero is returned. > > **中文翻译：** > 函数返回转换后的值（若存在）。若无法执行任何转换，则返回正零或无符号零。标准要求调用方使用的是 `endptr` 指针参数，解析后通过检查 `endptr == nptr`（即结束指针依然等于起始字符串指针，说明没有任何字符被解析）： > *Instead, you're supposed to use the `endptr` parameter, and check afterward if `endptr == nptr` (i.e. the end pointer is the same as the start pointer, so no data was parsed):* > `7.25.2.6p8`: > > > If the subject sequence is empty or does not have the expected form, no conversion is performed; the value of `nptr` is stored in the object pointed to by `endptr`, provided that `endptr` is not a null pointer. > > **中文翻译：** > 若目标字符序列为空或不符合预期格式，则不进行转换；在 `endptr` 不是空指针的前提下，`nptr` 的值将被存入 `endptr` 所指向的对象中。 Linux 手册页 `strtod(3)` 也有类似的表述： > *The man page `strtod(3)` says something similar:* > > If no conversion is performed, zero is returned and (unless `endptr` is null) the value of `nptr` is stored in the location referenced by `endptr`. > > **中文翻译：** > 若未执行任何转换，函数返回零，并且（除非 `endptr` 为空）将 `nptr` 的值存入 `endptr` 引用的位置。但再来看看 POSIX 规范是怎么规定的： > *But check out what posix says:* > > Upon successful completion, these functions shall return the converted value. If no conversion could be performed, 0 shall be returned, and `errno` may be set to `[EINVAL]`. > > **中文翻译：** > 成功完成时，这些函数应返回转换后的值。若无法执行任何转换，应返回 0，且**可以**将 `errno` 设置为 `[EINVAL]`。这里的关键用词是“可以（may）”，在标准术语里意味着它属于“由实现定义（implementation-defined）”的可选行为。这会带来灾难性的兼容性隐患！因为不少程序员和代码教程里常常这么检查错误： > *The word "may" basically means that it's implementation-defined. but this is a big deal, because it's pretty common to check for errors by doing something like this:* ```c errno = 0; double x = strtod(s, nullptr); if (errno != 0) { // ... 报错逻辑 } ``` 甚至 `strtod(3)` 的 Linux 手册页本身就官方建议大家这么写： > *`strtod(3)` suggests doing exactly this:* > > Since 0 can be legitimately returned on both success and failure, the calling program should set `errno` to 0 before the call, and then determine if an error occurred by checking whether `errno` has a nonzero value after the call. > > **中文翻译：** > 由于无论成功还是失败都可以合法地返回 0，调用程序应在调用前将 `errno` 设置为 0，并在调用后通过检查 `errno` 是否为非零值来判断是否发生错误。然而，即便是针对标榜兼容 POSIX 的不同 C 运行库，这种写法也是**完全不可移植**的！不同的合规 libc 在无法进行转换时的行为截然不同。来看下面这个测试： > *But even for posix-compatible libcs, this isn't portable! different conforming libcs may behave differently if no conversion can be performed. in fact...* ```c errno = 0; strtod("x", nullptr); printf("%d\n", errno); ``` 在 glibc（大多数标准 Linux 发行版使用的 GNU C 库）上运行，这行代码会打印出 `0`，因为 glibc 的 `strtod` 绝不会将 `errno` 设置为 `EINVAL`。但如果你在 musl（Alpine Linux 及众多嵌入式系统使用的 libc）上运行，它**确实会将 `errno` 设为 `EINVAL`**，输出结果为 `22`（即 Linux 上的 `EINVAL` 错误码）。**而这一点在 Linux man page 上根本找不到任何记载**。 > *On glibc, this prints 0, because glibc's `strtod` never sets `errno` to `EINVAL`. musl, on the other hand, does set `errno` to `EINVAL`, so this prints "22". **this is completely undocumented on the linux man page**.* 而且按照我对 ISO C 标准的解读，musl 的做法并不符合标准 C，因为它在一个已有明确记录错误条件（溢出/下溢）的函数中，为无记载的场景设置了非零的 `errno`（在标准 C 眼中，非数字的无效输入并不是一个设置 errno 的错误条件）。musl 也许可以辩解说，由于它在 `math.h` 函数中不设置 `errno`，因此 `strtod` 描述里的 `errno` 条件不再适用，所以不存在所谓的“文档记载的 errno 用途”。但这种说法显然非常牵强。 > *It's also, from my reading of the standard, not conformant to standard c, because it's setting `errno` to a nonzero value in a function with other documented error conditions (and as far as standard c is concerned, invalid input isn't an error condition). musl could defend itself by saying that, because it doesn't set `errno` in its `math.h` functions, the `errno` condition in `strtod`'s description no longer applies, therefore there's no documented use for `errno` (since the use of `errno` is dependent on the value of `math_errhandling`). but that's clearly a stretch.* 不管怎样，很明显 C 语言标准委员会在这里需要给出更清晰无歧义的文字措辞。 > *Either way, it's clear to me that the standard needs clearer wording here.* --- ## 结论 / Conclusion 为了加深理解，文末我整理了一份在不同环境下检查字符串转浮点数错误的“正确”姿势清单： > *Just for fun, i figured i'd conclude with a list of all the "correct" ways to check for errors in the string to float conversion functions, just to hammer the point home:* ### 1. 溢出（Overflow） * **目标平台为 POSIX 环境：** 在调用前将 `errno` 置为 0，调用后检查： `copysign(result, 1.0) == HUGE_VAL && errno == ERANGE` *(注：`copysign` 用于取绝对值对比，避免处理符号位细节)*。 > *If you're targeting posix, set `errno` to 0 before the call, and afterward check `copysign(result, 1.0) == HUGE_VAL && errno == ERANGE`.* * **目标平台为纯标准 C（严格跨平台）：** 调用前将 `errno` 置为 0 **且** 调用 `feclearexcept(FE_OVERFLOW)`。如果调用后 `copysign(result, 1.0) == HUGE_VAL`，则根据 `math_errhandling` 的指示去检查 `errno == ERANGE` 或者调用 `fetestexcept(FE_OVERFLOW)`。如果你的代码只针对某一个特定的库实现，且你预先知道它支持哪种方式，可以省去对 `math_errhandling` 的判断，只保留对应的一种即可。 *注意：* 如果你使用了 `feclearexcept` / `fetestexcept`，必须确保编译器知道你会访问浮点环境。在 GCC 下对应的编译选项是 `-ftrapping-math`（通常是默认开启，除非开了 `-ffast-math`）。C 标准本身也提供了编译指令 `#pragma STDC FENV_ACCESS ON`，但 GCC 至今并不支持该 pragma。 > *Otherwise, set `errno` to 0 and call `feclearexcept(FE_OVERFLOW)` before the call, and, if `copysign(result, 1.0) == HUGE_VAL`, either check `errno == ERANGE` or `fetestexcept(FE_OVERFLOW)` after the call, depending on the value of `math_errhandling`.* > *If you're targeting just one implementation, and you know which error-reporting methods it supports beforehand, you can skip the `math_errhandling` check and only support one of the two methods.* > *If you're using `feclearexcept`/`fetestexcept`, make sure that the compiler knows you may be accessing the floating point environment: on gcc the relevant flag is `-ftrapping-math`, which is the default (unless you're using `-ffast-math`). there's also a standard pragma for this purpose: `#pragma STDC FENV_ACCESS ON`. this pragma isn't supported by gcc though.* --- ### 2. 下溢（Underflow） * **目标平台为 POSIX 环境：** 在调用前将 `errno` 置为 0，调用后检查： `result == 0.0 && errno == ERANGE`。 **务必明确检查 `errno` 是否等于 `ERANGE`，而不能仅仅检查它是否非零（`errno != 0`）！** 否则遇到像 musl 那样把无效输入设为 `EINVAL` 的库时，你的逻辑就会出现非可移植的误判。 > *If you're targeting posix, set `errno` to 0 before the call, and afterward check `result == 0.0 && errno == ERANGE`.* > *Be sure to check specifically that `errno` is `ERANGE`, not just that it's nonzero. otherwise you'll end up with nonportable behavior.* * **目标平台为特定单一实现：** 查阅该库的手册，看它是否记录了在 `` 函数发生下溢时的行为。标准规定该行为属于“由实现定义”，因此理论上库必须给出文档说明。但在现实中，连 Clang/LLVM 这类编译器工具链很多时候都懒得去写这些实现定义的细则，所以别抱太大希望。但如果它确实有记录并支持报告下溢，那么根据其 `math_errhandling` 的配置，要么在调用前清零 `errno` 并在调用后检查 `result == 0.0 && errno == ERANGE`；要么在调用前执行 `feclearexcept(FE_UNDERFLOW)` 并在调用后检查 `fetestexcept(FE_UNDERFLOW)`。 > *Otherwise, if you're just targeting one implementation, check if it documents its behavior on underflow in `math.h` functions. the behavior is implementation-defined, so technically it's required to document it. but in practice, even clang doesn't bother documenting its implementation-defined shit, so don't hold your breath.* > *But if it is documented, and it reports underflow errors, then, depending on the implementation's value of `math_errhandling`, either set `errno` to 0 before the call and check `result == 0.0 && errno == ERANGE` after the call, or call `feclearexcept(FE_UNDERFLOW)` before the call and check `fetestexcept(FE_UNDERFLOW)` after the call.* * **目标为纯标准 C 且要求通用：** 那就彻底听天由命了（SOL - Shit Out of Luck）。如果你**真的、非常迫切**需要检测下溢，又因为某些原因非得使用系统 libc 的转换函数，那我能想到的唯一办法是：首先检查 `result == 0.0`，如果为零，你得亲自扫描原始字符串，看看在指数部分（`e` 或 `E`）之前是否存在任何非零有效数字。如果输入字符串本身包含非零数字但转换结果却变成了零，说明必然发生了下溢。但要完全正确地手工解析边缘情况极其困难，你必须仔细阅读标准中对 `strtod` 的完整格式定义，确保覆盖所有 corner case。 > *Otherwise you're SOL.* > *If you reeally need to check for underflow, and you need to use the libc function for some reason, here's the only option i can think of: check if `result == 0.0`, and if so, check yourself if the input string contains any nonzero digits before the exponent. if so, underflow occurred. this is difficult to get right though; read the description of `strtod` et al from the standard and make sure you cover all edge-cases.* --- ### 3. 无效输入（无法执行任何有效转换） * **通用做法：** 给函数传入第二个参数 `&endptr`，并在调用后对比检查是否 `endptr == nptr`。 **切记：在任何跨平台代码中，绝对不能依赖 `errno` 来判断输入是否合法！** > *Pass in `&endptr` as a second argument to the function, and then check if `endptr == nptr`. `errno` can't be relied on.*

评论