我的观点是,如果由于需要能够保存或(-1)的任何可能值,C实现不能满足某些stdio函数(特别是fputc/ fgetc)的规范.这个推理是否正确？sizeof(int)==1intunsigned charEOF
(显然sizeof(int)不能为1,如果CHAR_BIT是8,由于所需的最小范围int,所以我们隐含地仅讨论与CHAR_BIT>=16例如DSP的实现,其中典型的实现将是独立实现而不是托管实现,因此不需要提供stdio.)
编辑:在阅读了答案和一些链接引用后,对托管实现可能有效的方式有一些想法sizeof(int)==1:
首先,一些引用:
7.19.7.1(2-3):
如果未设置stream指向的输入流的结束指示符并且存在下一个字符,则fgetc函数将该字符作为转换为int的unsigned char获取并为该流提前关联的文件位置指示符(如果定义).
如果设置了流的结束指示符,或者流处于文件结尾,则设置流的结束指示符并且fgetc函数返回EOF.否则,fgetc函数返回stream指向的输入流中的下一个字符.如果发生读取错误,则设置流的错误指示符,并且fgetc函数返回EOF.
7.19.8.1(2):
fread函数在ptr指向的数组中,从stream指向的流中读取大小由size指定的nmemb元素.对于每个对象,对fgetc函数进行大小调用,并按顺序读取存储在unsigned char数组中的结果,该数组恰好覆盖对象.流的文件位置指示符(如果已定义)按成功读取的字符数提前.
思考:
读回unsigned char范围之外的值int可能只是在实现中具有未定义的实现定义的行为.这是特别令人不安,因为它意味着使用fwrite和fread存储二进制结构(这同时导致不可移植的文件,应该是你可以在任何单个实现便携执行操作)可能出现的工作只是默默地失败.基本上总是导致未定义的行为.我接受的实现可能没有一个可用的文件系统,但它的很多难以接受的实现可以有一个文件系统,当你试图用它那就会自动调用鼻鬼,没有办法判断它的不可用. 现在,我意识到行为是实现定义的,而不是不确定的,它不是这么不安,我想这可能是一个有效的(虽然不受欢迎)的实现.
实现sizeof(int)==1可以简单地将文件系统定义为空且只读.然后,就没有办法应用程序可以读取本身写的,只从一个输入设备的任何数据stdin可能被实现为只给予积极的char配合在价值观int.
编辑(再次):从C99理由,7.4:
EOF传统上是-1,但可以是任何负整数,因此可以与任何有效的字符代码区分开.
这似乎表明sizeof(int)可能不是1,或者至少这是委员会的意图.
EOF总是负面的吗？
我正在考虑编写一个函数来读取输入中的下一个单词并返回找到该单词的行号或者如果已到达输入结尾则返回EOF.如果EOF不一定是负数,则函数将是不正确的.
POSIX定义EOF为扩展为负值的宏:
标头应定义以下宏,该宏将扩展为具有int类型和负值的整数常量表达式:
EOF
文件结束返回值.
在每一个我能找到的实现,EOF是始终定义为-1.
虽然标准确实允许不同的值,但我找不到任何特定的实现,并且我想找到一个用于测试目的.1
1 我可以自己实现,但我的真正目的是"在野外找到它",由于不可能证明它不存在,这是我能想到的下一个最好的事情.
已经提出了一个几乎相同的问题,但最后提出了两个问题,接受的答案只回答了第二个问题(约WEOF).一个不同的用户回答了第一个问题,但由于问题仅限于普通的C环境,否则可以说是正确的:-1可能用于任何具有小字符类型的合理实现.
由于我的问题是关于存在,实际回答它的唯一方法是提供一个例子,所以我将重新说明它:请提供一个现有实现的例子EOF != -1.无论是newlib还是musl,PDP或VAX,Plan 9或Hurd,libc /硬件/操作系统与POSIX兼容或ISO C兼容的libc的任何组合都是有效的.