这看起来像是解析器中的一个极端情况。XeY在第10.3.1节中描述：R Language Definition的文字常量，指向?NumericConstants以获取“当前接受格式的最新信息”。
问题似乎出在解析器如何处理指数，数字常量由NumericValue处理（main/gram.c的第4361行），它调用mkFloat（main/gram.c的第4124行），R_atof调用main/util.c的第1584行），R_atof调用R_strtod4（main/util.c的第1461行）。（所有这些操作都是从修订版60052开始的。）
main/utils.c的第1464行显示expn声明为int，如果指数太大，它将在第1551行溢出。有符号整数溢出导致未定义的行为。
例如，下面的代码为指数〈308左右生成值，为指数〉308生成Inf。

const <- paste0("1e",2^(1:31)-2)
for(n in const) print(eval(parse(text=n)))

您可以看到指数〉2^31时的未定义行为（指数= 2^31时R挂起）：

const <- paste0("1e",2^(31:61)+1)
for(n in const) print(eval(parse(text=n)))

我怀疑这会引起R-core的注意，因为R只能存储大约2 e-308到2 e +308之间的数值（参见?double），而这个数字远远超过了这个数字。

这很有趣，但我认为R在解析指数非常大的数字时存在系统性问题：

> 1e10000000000000000000000000000000
[1] 0
> 1e1000000000000000000000000000000
[1] Inf
> 1e100000000000000000000
[1] Inf
> 1e10000000000000000000
[1] 0
> 1e1000
[1] Inf
> 1e100
[1] 1e+100

好了，终于有合理的解释了。根据这个输出和约书亚Ulrich下面的注解，R似乎支持表示最大为2e308的数字和解析指数最大为+2 ×10^9的数字，但它不能表示它们。在那之后，显然由于溢出而有未定义的行为。

• R* 有时可能会使用bignums。也许1e9999999999999999999999999999999是某个阈值，或者解析例程阅读指数的缓冲区有限。您的观察结果与32个字符（以空结尾）的指数缓冲区一致。

我宁愿在论坛或邮件列表上问这个问题，据说这是友好的。
或者，由于 R 是自由软件，您可以研究它的源代码。

R有时可能会使用bignums。也许1e999999999999999999999999999是某个阈值，或者也许解析例程有一个有限的缓冲区来阅读指数。您的观察结果将与32个字符（以空结尾）的指数缓冲区一致。
我宁愿在R的论坛或邮件列表上问这个问题，据说这些论坛或邮件列表很友好。
或者，由于R是自由软件，您可以研究它的源代码。