- 主题:上午面试了一个小孩，问了一个问题是不是太过分了 (转载)
难道char 不是默认为signed吗？
【 在 anotherstone (初级K线分析员) 的大作中提到: 】
: 【 以下文字转载自 NewExpress 讨论区 】
: 发信人: feiy (null), 信区: NewExpress
: 标 题: 上午面试了一个小孩，问了一个问题是不是太过分了
: 发信站: 水木社区 (Thu Jul 8 18:25:14 2021), 站内
--
FROM 136.56.63.*
memset/memcpy的char难道不是默认带符号的类型？
【 在 ilovecpp (cpp) 的大作中提到: 】
: 类似memset, memcpy这种用途，还是应该用char。这里char并不是“字符类型”或者“整型”，而是“内存单元”。一个buffer的类型如果不是char*那应该是什么呢？
: 如果这里用u8，遇到像你说这种内存单元不是8位的就真错误了。而用signed/unsigned char的话，理论上有可能平台只能高效支持其中一种，另一种较低效。我想这也是C标准里char不默认为有符号的原因。
:
: 【 在 feiy 的大作中提到: 】
--
FROM 136.56.63.*
memset/memcpy的char难道不是默认带符号的类型？
【 在 ilovecpp (cpp) 的大作中提到: 】
: 类似memset, memcpy这种用途，还是应该用char。这里char并不是“字符类型”或者“整型”，而是“内存单元”。一个buffer的类型如果不是char*那应该是什么呢？
: 如果这里用u8，遇到像你说这种内存单元不是8位的就真错误了。而用signed/unsigned char的话，理论上有可能平台只能高效支持其中一种，另一种较低效。我想这也是C标准里char不默认为有符号的原因。
:
: 【 在 feiy 的大作中提到: 】
--
FROM 136.56.63.*
如果是做底层系统，这是常识
--
FROM 113.91.89.*
【 在 comus 的大作中提到: 】
: 关键这种问题没意义，现在代码有lint，有gcc warning检查，年轻人不懂也没关系，都会查出来的。
: 另外所有代码不应该不能用char_t，int32_t之类的代替char ，int的使用吗？（这个lint也能查出来）
: 而且，你的代码既然写的是-5，按你说的char被编译器当成uchar的话。编译能通过，我也是醉了…
顶这句，char被编译器当成uchar，-5赋给它，编译大概率不过
lz就是典型的想考某个知识点，但实际出的题目根本不严谨，被面的人很可能抓不住你的点，一点意思都没有
: ...................
--
FROM 183.136.182.*
这个你说得不对。首先C语言不论指针的值还是sizeof，都是以char为单位的。不论它内部用什么指令实现，memcpy(dst,src,N)一定是复制了N个char。那么它最朴素的实现，也就是一个char*上的循环。
当然今天以前，我会觉得char不是8位只是理论上的可能性，你在memcpy里用u8也没问题。但是现在我们知道，确实有编译器可以设定为16位char，那么在此模式下memcpy的长度参数必定是以16位为单位计数的。如果两个指针的值差1，它们之间也必定差16位。
【 在 feiy 的大作中提到: 】
: 若想最终确认你的说法在各个场景对不对，最好的办法对着编译结果(上下几条汇编)看看吧，他用啥指令搬运，8位指令还是32位的搬运指令，也可能优化的目的，混杂都有。这是最靠谱方法。所以你说的不绝对，memcpy之类基本还是以8-bit字节为计数，指向的缓冲区或内存地址，依然可以视作是以字节为计数的，所以你用u8*大概率毫无问题(最多个可忽视不影响的warning)，严格说来，u8*这是个指标本身不是8位的，可能是32位的。只是在某些平台某些场合上有类似32位对齐的要求，就是u8*这个指针的值(地址)必须是32位对齐的，但不代表是按32位复制，或必须是u16*或u32*。
: 不知我表达清楚没有，你酌情看吧。扯远了，估计一些人看着会懵认为是啥也没说瞎扯淡了。我的回答是，不一定，看编译结果。
: --来自微水木3.5.11
--
FROM 114.86.93.*
我说的不是符号问题。
我的意思是“记得标准库函数对后面的个数是以8-bit为单位”不对。memcpy, memset, sizeof都是以char为单位。
所以你要表示一个内存单位时就应该用char。用u8或s8都不对。
例如：
char buf[sizeof(MyStruct)*10];
而不是
u8 buf[sizeof(MyStruct)*10];
【 在 feiy 的大作中提到: 】
: 对于memset/memcpy，复制的数，分辨char带不带符号，其实没多大关系，因为只是个存储而已。一个8-bit空间全是bit1，若对应的变量是s8，那就按-1理解，若对应的是u8，那就按255理解而已。
: 是不是有符号的，主要在比较等场合会有影响。会影响编译器根据其符号选择不同的比较指令或处理方式。
: 很多加减场合基本无影响(当然，有些时候可能会牵涉到溢出位数转化，具体分析吧)。
: ...................
--
FROM 114.86.93.*
我好像是从Herbert Schildt的C语言大全里看的，
这是我学C看的第一本书，然后就记住了，然而
实践中也没玩过默认是unsigned的环境-_-;;;;
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 能知道C语言里char、signed char 和 unsigned char是三种不同类型的人，要不就是仔细看过编译器说明书，要不就是啃过一点标准，要不就是从汇编时代走过来的。这种人凤毛麟角。考虑到现在的小朋友几乎没有任何渠道可以获取到这类知识，你的要求好像是高了一点。。
--
FROM 183.156.100.*
那要按这逻辑也不应该存在未指明长度的int，
只允许存在int8、int16、int32、int64 @.@
【 在 amt6 (amt6) 的大作中提到: 】
: 我认为就不应该存在char=unsigned char。要这么玩，就不应该存在char，只允许存在signed char或unsigned char。
--
FROM 183.156.100.*
我不是说不需要知道这些问题，这个问题本身也不是啥大问题。如果你觉得这个人整体素质满意，即使他不知道这个问题也只是说一句话就能教会的事情。在我看来这种问题没必要问，问了没任何收益，反倒是降低了你在面试者眼中的身份。
我的意思是，比起现状，更重要的是往什么方向走，乘着什么波浪走。现在的IT技术已经不再是以前的手工业时代了，要拥抱新的技术，拥抱成系统成体系规范化的做法。至于你说的各种现状和形形色色的bug问题，你要想清楚这是你现在要解决的首要矛盾还是次要问题。如果这是你的首要矛盾，那你就应该招一个精通处理这方面经验的老中医角色的人。那你的jd和面试完全可以照着这个来，怎么细节怎么搞都可以。如果你招的是一个开发，那他就是来给你生产东西，而不是给你解决疑难杂症的。他能在你的生产体系里面达标能高效产出即可，同时你的生产体系也不能是小作坊形式，而是为了能高效产出合格的代码而配套的一整套体系。哪怕现状是小作坊，至少方向上也要向工业化标准看齐，所以我才强调这个方向的问题才是核心。
老一辈工程师都经历过这种用各种奇淫技巧在螺蛳壳里做道场的时代，但现在时代变了，你可以说作为过来人这是一种宝贵的经历和精神，但这种精神现在是不值得提倡的。比如cube这种东西肯定是未来，我不喜欢只是现在这个时间点，目前cube做的太烂了，还不够好，还没达到我心目中的标准。但这种东西给予一定的时间是肯定会改良到合格的状态的。但你不能因为这种东西现状不好所以就抱着以前的方法不放。一定要逼着自己升级自己的思路和技术，要跟现在的时代同步。
【 在 feiy 的大作中提到: 】
: 彻底消除char这种用法，是对的。公司代码审查规则必须有这一条。
: 我只是基于我协助解决过的许多朋友的形形色色的bug经验，知道很多公司很多工程师并不在乎使用char，这是个现实。
: 这是现实，如果你知道这里的问题风险，不是更好或必要吗？
: ...................
--
FROM 180.111.50.*