问题标签 [c-standard-library]

我现在使用 Windows 和 Visual Studio 10.0。

我想知道在 stdio.h、string.h 等中声明的 C 标准库函数的目标文件在 Windows 中的位置，因此搜索了“stdio.h”的目标文件但失败了。

如下，

库文件夹中的文件

这些都在 C:\Program Files\Microsoft Visual Studio 10.0\VC\lib 中。

哪个是“stdio.h”的目标文件？或者'stdio.h'的目标文件是否在另一个路径中？

仅在该路径中是否有 C 标准库的目标文件？

有谁知道为什么参数类型为putchar(), fputc()and putc()is char，但参数类型为putwchar(), fputwc()and putwc()is wchar_t？另请参见this和this。

为什么islower()and friends 需要处理EOF，而putchar()and friends 不需要？

为什么不islower()对待intas unsigned char，因为它是这种情况putchar()？这完全有道理，因为EOF无论如何我们都必须先检查。另请参阅为什么putchar(),fputc()和putc()is not的参数类型char？

引入 wchar_t 的 ISO C90 标准没有说明有关表示的任何具体内容。它只要求这种类型能够存储基本字符集的所有元素。

这意味着 thatwchar_t很可能是 type char，并且wint_t可能是 type int。此外，在一些实施wchar_t方式中，可能是有符号的，而在一些实施方式中，可能是无符号的。情况有何不同putchar()？

为了比较， 和 的putchar()论点putc()被fputc() 选为int。

我认为处理单个字符的库函数都不能与（char仅与）一起使用，因为int即使其中一些不使用 EOF（如的签名不是标准化的），会有类型转换警告，如putchar()charcharunsigned charchar

所以唯一的选择是做它int，它可以同时保存有符号和无符号char。

尽管参数被 putchar() 自动转换unsigned char为 int 或signed char 形式，但在 putwchar() 中没有进行任何排序。

那么，为什么fputwc()，putwc()并putwchar()采取wchar_t，不是wint_t？似乎是标准中的一个缺陷。我错过了一些明显的东西吗？

另请参阅为什么需要 islower() 和朋友来处理 EOF？为什么论点类型是putchar(),fputc()putc()char而不是？以及glibc 中 fputwc()、putwc() 和 putwchar() 的定义不一致

更新

来自 glibc 参考的一些引文

ifwchar_t被定义为char类型wint_t必须被定义为int由于参数提升。

定义wchar_t为char

事实上，这些功能在“ISO Working Paper SC22/WG14/N204 日期为 1992 年 3 月 31 日”（这是发布“ISO/IEC 9899:1990/Amendment 1:1995”之前的最终草案）中具有正确的接口，但是它们被更改了在“ISO/IEC 9899:1990/修正案 1:1995”中。见这里http://www.unix.org/version2/whatsnew/login_mse.html

标准里写的EOF一定是负数吗？相反，WEOF不需要为负数。为什么？for 的情况wchar_t不得与普通情况有任何不同char（除非自动提升 from chartoint发挥作用），因为定义wchar_taschar完全符合标准。因此，必须适用类似的规则。

glibc 参考中的一些引用：

ifwchar_t被定义为char类型wint_t必须被定义为int由于参数提升。

定义wchar_t为char

char 的符号没有标准化。因此有signed char和unsigned char类型。因此，使用单个字符的函数必须使用可以同时包含有符号字符和无符号字符的参数类型（这个类型被选择为int），因为如果参数类型是char，我们会从编译器收到类型转换警告（如果 -Wconversion使用）在这样的代码中：

（这里我们考虑如果 islower() 的参数类型是 char 会发生什么）

让它在没有显式类型转换的情况下工作的事情是从charto自动提升int。

此外，wchar_t引入的 ISO C90 标准没有具体说明wchar_t.

glibc 参考中的一些引用：

定义wchar_t为char

ifwchar_t被定义为char类型wint_t必须被定义为int由于参数提升。

因此，wchar_t可以很好地定义为char，这意味着必须适用于宽字符类型的类似规则，即，可能存在 wchar_t肯定的实现，也可能存在wchar_t否定的实现。由此得出，必须存在unsigned wchar_t和类型（出于与存在和signed wchar_t类型相同的原因）。unsigned charsigned char

私人通信表明允许实现仅支持具有 >=0 值的宽字符（与 的符号无关wchar_t）。有人知道这是什么意思吗？薄是不是意味着当wchar_t是16位类型时（例如），我们只能使用15位来存储宽字符的值？换句话说，符号扩展wchar_t是否是有效值？另请参阅此问题。

此外，私人通信表明该标准要求 的任何有效值wchar_t必须由 表示wint_t。这是真的吗？

考虑这个例子：

为了使其可移植，我们需要强制转换为 '(unsigned char)'。这是必要的，因为char可能是等价的signed char，在这种情况下，设置了最高位的字节在转换为时将被符号扩展int，从而产生一个超出范围的值unsigned char。

现在，为什么这种情况与下面的宽字符示例不同？

我们需要在iswlower((unsigned wchar_t)wc)这里使用，但是没有unsigned wchar_t类型。

为什么没有unsigned wchar_t和signed wchar_t类型？

更新

标准是否说在以下两个程序中的转换unsigned int和转换int是正确的？（我只是在glibc中替换wint_t了它们的实际含义）wchar_t

--

我看到 glibc 参考和 C90 修正案 1 的一个矛盾。

glibc reference 中的引用说 wchar_t 可能会提升为 wint_t：

如果 wchar_t 定义为 char 类型 wint_t 必须定义为 int 由于参数提升

但是 AMD1 是这样说的：

目前，现有实现可能将 wchar_t 设置为 int 并将 wint_t 设置为 long，并且默认促销不会将 int 更改为 long。基本上，这是由于 wchar_t 和 wint_t 是 typedef。因此，我们现在不会将 wchar_t 提升为 wint_t。

有人知道哪一个是正确的吗？

标准是否说在以下两个程序中强制转换为 unsigned int 和 int 是正确的？（我只是替换wint_t了wchar_t它们在 glibc 中的实际含义）（我只是替换wint_t了wchar_t它们在 glibc 中的实际含义）

--

标准是否说在以下两个程序中的转换wint_t和转换wchar_t是正确的？

--

考虑wchar_tis signed short（这个假设的实现仅限于 BMP）、wint_tissigned int和的情况WEOF == ((wint_t)-1)。则(wint_t)U+FFFF与 无异WEOF。是的，U+FFFF是一个保留的代码点，但它碰撞仍然是错误的。

如果没有对现有实现进行详尽的审计，我不想发誓这在现实生活中永远不会发生。

另请参见wchar_t 是否可以提升为 wint_t？

基本上我正在寻找的是一个标准函数，它可以做这样的事情

这个特定的例子假设target和src是相同的长度，但这不是我正在寻找的必要先决条件。虽然c假设出现在src.

例如transcpy(word, "word", 'r");where word is"____"会改变 word to be"__r_"

这可能只是特定于实现一个刽子手游戏，但它似乎是一个足够有用的功能，它可能有一个标准实现

假设log()in的函数<cmath>声明在全局命名空间中（这实际上是未指定的，我们只是做这个假设），那么它引用的函数与log()我们定义的函数相同。
那么这段代码是否违反了单一定义规则（见这里，因为不需要诊断，这段代码可以在某些编译器中编译，我们无法断言它是否正确）？

注意：经过最近的编辑，这不是以下内容的重复：C++ 中的一个定义规则到底是什么？