若干C ++源材料和堆栈溢出问题讨论了与实现有关的性质char。也就是说，char在C ++中可以将其定义为an unsigned char或a signed char，但是根据ARM Linux FAQ ，此实现完全取决于编译器：
上面的代码实际上是错误的，因为它假定类型“ char”等效于“ signed char”。C标准确实说过，“ char”可以是“ signed char”或“ unsigned char”，这取决于编译器的实现或所遵循的平台。
这为歧义问题和不良做法（包括误以为 8位数字使用的char的符号）都敞开了大门。C的基本原理提供了这种情况的某些原因，但没有解决保持歧义可能性的问题：
指定了三种类型的char：有符号，无格式和无符号。像以前的实践一样，根据实现方式，纯字符可以表示为有符号或无符号。引入了带符号的字符类型，以在那些将无格式字符实现为无符号的系统上提供一个一字节的带符号整数类型。出于对称性原因，允许使用符号关键字作为其他整数类型的类型名称的一部分。
将门关闭甚至产生歧义的可能性似乎是有利的，只留下unsigned char和signed char的类型作为8位单元的两种数据类型。这促使我提出问题...
鉴于存在歧义的可能性，为什么还要保留char数据类型实现的依赖性？
一些处理器更喜欢带符号的字符，而另一些处理器更喜欢无符号的字符。例如，POWER可以从内存中以零扩展名而不是符号扩展名加载8位值。但是SuperH-3可以从内存中加载带符号扩展名但不能扩展为零的8位值。C ++派生自C，而C留下了语言实现定义的许多细节，因此可以对每个实现进行定制，使其对其目标环境最有效。