memset/memcpy的char难道不是默认带符号的类型？  
  
【 在 ilovecpp (cpp) 的大作中提到: 】
:  类似memset, memcpy这种用途，还是应该用char。这里char并不是“字符类型”或者“整型”，而是“内存单元”。一个buffer的类型如果不是char*那应该是什么呢？
:  如果这里用u8，遇到像你说这种内存单元不是8位的就真错误了。而用signed/unsigned char的话，理论上有可能平台只能高效支持其中一种，另一种较低效。我想这也是C标准里char不默认为有符号的原因。
:  
:  【 在 feiy 的大作中提到: 】
--
FROM 136.56.63.*

说的对，谢谢。

【 在 feiy 的大作中提到: 】
: 对于memset/memcpy，复制的数，分辨char带不带符号，其实没多大关系，因为只是个存储而已。一个8-bit空间全是bit1，若对应的变量是s8，那就按-1理解，若对应的是u8，那就按255理解而已。
: 是不是有符号的，主要在比较等场合会有影响。会影响编译器根据其符号选择不同的比较指令或处理方式。
: 很多加减场合基本无影响(当然，有些时候可能会牵涉到溢出位数转化，具体分析吧)。
: ...................
--
FROM 216.240.30.*

查了一下k&r：
char    a single byte, capable of holding one character in the local character set

The qualifier signed or unsigned may be applied to char or any integer. unsigned numbers are always positive or zero, and obey the laws of arithmetic modulo 2n, where n is the number of bits in the type. So, for instance, if chars are 8 bits, unsigned char variables have values between 0 and 255, while signed chars have values between -128 and 127 (in a two's complement machine.) Whether plain chars are signed or unsigned is machine-dependent, but printable characters are always positive.

【 在 ilovecpp 的大作中提到: 】
: 考虑到int全部默认signed，唯独char不同。大概是设计C语言时，各种cpu都能直接操作有符号word，而存在cpu（或者设计者以为存在cpu）只能操作无符号byte，有符号byte需要软件模拟。
: :
--
FROM 216.240.30.*

历史遗留

【 在 chylli 的大作中提到: 】
: 为啥C标准会弄这么多未定义的玩意？这不是找麻烦么？
:
--
FROM 216.240.30.*

哎呦妈呀，居然还有取48的，汗。

【 在 lvsoft 的大作中提到: 】
: 大致的历史是先有6bit，构成常用字符数字集。这也是base64编码的内容。
: 之后到了7bit，加入了控制符。
: 再后面到了8bit，加入了制表符。
: ...................
--
FROM 216.240.30.*