昨天群友发文询问，为什么C语言里bool似乎占用4Byte，给bool赋值后，它后面的3个字节 内容也被修改了，并且她还强调代码没有经过编译器优化（-O0是关闭优化的意思）。
从汇编角度来说，如果“test %al, %al”能改成“test %0x1, %al”就没有匪夷所思的问题了，如此一来应该会降低CPU的效率，毕竟执行指令还需要一个立即数，我没搞过编译器也没设计过CPU，纯属瞎猜，能搞编译器的家伙都是大牛的存在，咱们吃瓜的参合个啥！
Linux电脑输入poweroff退出操作系统后电源会自动切断，而嵌入式Linux如果没做特殊处理 输入poweroff关闭系统后电源依旧保持着。敲击键盘也不会有响应。原因是CPU和主板之间有着行业标准，比如ACPI（Advanced Configuration and Power Interface）、 APM（Advanced Power Management），都有相应的硬件IO状态指示。
初定采用图像识别的方法，图像文字提取有很多现成方案，而且还是显示器上的文字提取，比车牌识别要简单得多，就算不答应他，我也想自己试试玩玩。计划几天的工作量，没打算在它身上废太多功夫。一切的创新从拷贝开始，没想到3小时就把功能实现，接下来抽空上一点细节，以及各种异常处理，毕竟要规避少量误报的情况。
最近某项目采用以太网通信，实践起来有些奇怪，好像设计成只能应答某类计算机的ICMP（ping）命令， 某类计算机指的是Windows特定系统，其他系统发送ping都不能正确识别。
文章计算WIFI6采用1024-QAM时需要将相位分割成636份，2.4G频率下硬件的响应速度要至少达到0.6ps级别。
我们学校的定位是给企业输送“运维”人员，至于“设计”人员不再考虑范围之内， 只需要学生明白设备的工作原理、流程即可，培养具备设计能力的学生即累老师也累学生。
在我看来最不值得一提的BUG是那种可以重复复现的，他的稳定复现通常排查起来没啥技术含量， 早些年我处理一个不值得一提的BUG，BUG也很好复现，难点是复现时间固定在4小时左右，BUG由于文件资源未释放引起进程访问文件数目受限而崩溃，早期Android系统用该BUG获取到root权限， 本文向你分享，如何根据错误提示和参考手册找到故障点，指导新码农如何正确阅读Linux帮助手册（man page）， 最后总结我的排查过程给小白一点实用的建议。好下面开始不如步入正题。需要调试的是一个监控程序，代码非常简单，2个线程执行不同的任务，每个任务都是间隔15秒执行一次，程序固定在大约4小时后崩溃。代码简单到用不着任何同步机制、没有任何通信，极少的内存访问，按理来说他就不应该存在BUG，然而还是发生了。
