为何strtol()等转换函数的第二个参数不指向const数据？

核心原因：历史兼容性的妥协 #

这些字符串转数值的函数早于C语言中const关键字的出现——const是C89标准才正式加入的特性。在早期的C实现里，根本没有只读内存的概念，函数参数全是非const指针。当const被引入后，标准委员会不敢轻易修改这些函数的参数类型：如果改成const char**，所有旧代码里传递char**的写法都会直接编译失败，这会引发大规模的兼容性问题，所以只能保留原有的参数类型。

传入const指针的风险 #

你给出的例子里，text是static const char[]，它的内存通常会被放在程序的只读数据段里。strtol会把第一个无法转换的字符地址（也就是例子里的空格）赋值给eon，而这个地址指向的是只读内存。此时执行*eon='\0'去修改这块内存，属于未定义行为——程序可能崩溃、输出乱码，或者在某些环境下看似正常，但这绝对是非法操作。

GCC开-Wall没报错，是因为C语言为了兼容旧代码，允许const char*隐式转换为char*。如果开启更严格的-Wwrite-strings选项，编译器就会警告你这种危险的转换。

关于你的猜测：函数是否区分字符的常量属性？ #

其实不是。函数内部只是单纯扫描字符串，找到第一个无法转换的字符后返回它的地址，根本不会去判断这块内存是不是只读。问题的根源还是历史遗留的参数设计，导致它无法区分输入字符串的可写性。

重实现时的正确做法 #

如果你要自己实现这类函数，最好提供两个版本：一个接受const char**（用于只读字符串），另一个接受char**（用于可写字符串）。但标准库只能保留非const版本来兼容旧代码，你在使用时要自己注意：

• 如果输入是const字符串，绝对不要通过返回的指针修改内存；
• 要是必须用const字符串调用，可以显式把const char*转成char*（但一定要确保原内存实际可写，否则还是会出问题），或者用const char**类型的指针接收结果，再强制转换传递给函数（不过这种写法不够优雅，不如直接管住自己的手不去修改）。

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