+ 本文将介绍UNIX网络编程中connect函数及其包裹函数。
1 |
|
connect函数用于客户端建立tcp连接，发起三次握手过程。其中sockfd标识了主动套接字，server_addr是该套接字要连接的主机地址和端口号，addrlen为server_addr缓冲区的长度。
连接失败时，可以根据以下errno值判断失败的原因：
1 | EBADF：参数sockfd 非合法socket处理代码; |
1 |
|
包裹函数为connect函数设置了超时重连的机制，如果连接成功，则成功返回。如果连接失败，则每次等待1、2、4、8。。。秒后继续尝试重新连接，直到MAXSLEEP为止。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/connect-in-unix/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ Shell脚本是用户与Linux操作系统交互的一种方式,在脚本编程过程中自然少不了进行调试工作,本文将介绍三种常用的调试方法.(默认使用bash shell)
+ + +使用**-x**选项可以打印出脚本执行的每一行命令以及当前状态.
有如下脚本,打印数字1到10:
1 | #!/bin/bash |
我们使用**-x**选项进行调试如下:
+1 | #在每一行前加上行号 |
有时候,你只需要对脚本的一部分进行调试,那么可以使用如下命令:
+1 | set -x #在执行时显示参数和命令 |
可以使用set builtin来启用或者禁止调试打印.
对上文脚本做如下修改:
1 | #!/bin/bash |
结果如下:
+1 | +test.sh:6:: echo 1 |
上面这种调试手段是bash内建的,而且输出格式固定而且繁琐.所以我们需要根据需要的信息,自定义格式来显示调试信息,通过设定_DEBUG环境变量来完成:
+1 | #!/bin/bash |
我们将_DEBUG环境变量设定为一个开关,只有打开时才会输出调试日志.
使用如上脚本结果如下:
1 | [aidu1602@ResU10 tools]$ _DEBUG=on sh debug.sh |
这样我们就可以自定义调试信息,并且可以控制调试开关啦.
+如果你需要调试一个非常复杂的脚本,并且需要一个及其专业的调试器,像GDB那样,那么我推荐这款开源的脚本调试器bashdb,具体使用可以参考它的文档.
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/debug-for-shell-script/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ DEBUG宏用于Linux下C编程时调试使用.
+ + +1 | /************************************************************************* |
1 | __LINE__：在源代码中插入当前源代码行号； |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/debug-macro/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ **:(){ :|: & };:**是一个bash函数，以Fork Bomb闻名，是一个拒绝服务攻击 的Linux 系统。如果你好奇地去执行了这个命令，那么赶快重启系统吧~！
+ + +1 | :() |
Linux中还有很多这样存在这陷阱的命令，这也正是我喜欢Linux系统的原因，充满着探索性。
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/fork-bomb/ +
发表日期：2016/07/14 13:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍C语言生成随机数的方法,主要使用 rand() 函数和 srand() 函数.
+ + +*rand()*函数是产生随机数的一个随机函数：
+1 | #include<stdlib.h> |
返回值：
*rand()*返回值为一随机数值，范围在0至RAND_MAX 间（RAND_MAX定义在stdlib.h，其值为2147483647）。
++注：在调用此函数前，必须先利用srand()设好随机数种子。如果未设随机数种子，rand()在调用时会自动设随机数种子为1。
+
代码：
+1 | /************************************************************************* |
运行结果：
说明：这里两次运行的结果相同，是因为未利用*srand()*设置随机数种子，所以rand()在调用时会自动设随机数种子为1。
+*srand()*函数是随机数发生器的初始化函数：
+1 | #include<stdlib.h> |
参数：
seed必须是个整数，通常可以利用*geypid()或time(0)的返回值来当做seed。如果每次seed都设相同值，那么rand()*所产生的随机数值会像上面的示例一每次就会一样。
代码：
+1 | /************************************************************************* |
运行结果：
哈哈，这下两次结果就不同了吧。
+关于随机数的知识就先总结这么多，以后碰到更复杂的再继续。
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/generate-random-numbers/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 心跳机制用于保持客户端和服务端的连接.
+ + +心跳机制就是当客户端与服务端建立连接后，每隔几分钟发送一个固定消息给服务端，服务端收到后回复一个固定消息给客户端，如果服务端几分钟内没有收到客户端消息，则视客户端断开。发送方可以是客户端和服务端，看具体需求。
+我们都知道在TCP这种长连接情况下下，有可能有一大段时间是没有数据往来的，即处于空闲状态。理论上说，这个连接是一直保持连接的，但是在实际应用中，如果中间节点出现什么故障是难以预测的。更可怕的是，有的节点会自动把一定时间之内没有数据交互的连接切断。所以，需要我们利用心跳机制，来维持长连接，保活通信。
+++注意：因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不默认开启KeepAlive。KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多应用程序来说，空闲时间太长。因此，我们可以手工开启KeepAlive功能并设置合理的KeepAlive参数。
+
这里具体介绍设置SO_KEEPALIVE套接字选项这个方法。
+1 | #include <sys/types.h> |
1 | int heartbeat(int fd) |
当然，还是有很多方法去实现心跳机制的，比如利用select实现的超时控制，或者利用守护进程或线程的单独检测。不过我个人认为设置SO_KEEPALIVE实现起来最简单，最方便。如果大家发现有什么问题，也欢迎大家交流。
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/keepalive-of-socket/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 字节流套接字（TCP套接字）上的read和write函数所表现的行为不同于通常的文件I/O。字节流套接字调用read或write输入或输出的字节数可能比请求的数量少，然而这并不是出错的状态。这是因为内核中用于套接字的缓冲区可能达到了极限。通常这种情况出现在一次读多于4096个字节或write在非阻塞情况下返回不足字节数。为了不多次调用read或防止write返回不足字节数，我们用下面的两个函数来替代read和write。
+ + +1 |
|
1 |
|
上面介绍了两个安全读写函数，但是并不意味着这两个函数在任何地方都完全适用，所以不要强迫自己使用。需要注意阻塞、效率等问题，当你只是读写少量字节时，就没必要使用了。
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/safe-read-and-write/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 在Linux开发环境下，想要录制一段屏幕视屏不是特别方便。这里分享给大家一种方便而且快捷的方法。
+ + +Linux下有script和scriptreplay这两个工具组合用于录制命令行。在新版本系统中，已经集成了这两个工具，所以直接使用即可：
+1 | $ script -t 2>timing.log -a >output.session |
说明：
+原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/script-and-scriptreplay/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ Linux下adb工具下载，下载解压到*/usr/bin*目录。
+ + +当我们在Linux下连接安卓手机，进行adb调试时，执行
+1 | $ adb devices |
会出现如下错误提示：
+1 | List of devices attached |
首先创建一个规则配置文件：
+1 | $ sudo vi /etc/udev/rules.d/70-android.rules |
保存并退出。
+查看USB设备信息，拔掉设备再查看一次，就可以比较出安卓设备是哪一个了，我的设备信息如下：
+1 | $ lsusb |
打开刚才的规则配置文件，写入如下内容：
+1 | SUBSYSTEM=="usb",ATTRS{idVendor}=="1f3a",ATTRS{idProduct}=="1002", MODE="0666" |
其中idvendor和idProduct指的是usb的id号，ID 1f3a是idVendor ，1002就是 idProduct。
+然后赋予文件权限
+1 | $ sudo chmod a+x /etc/udev/rules.d/70-android.rules |
重启udev：
+1 | $ sudo /etc/init.d/udev restart |
注意，这里一定要拔掉设备再重连！然后执行如下命令：
+1 | $ sudo adb kill-server |
显示信息如下：
+1 | * daemon not running. starting it now on port 5037 * |
那么说明连接成功，可以正常进行调试了。
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/07/14/solution-of-adb-devices-no-permissions/ +
发表日期：2016/07/14 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ Linux下链接的命令是ln,可以通过man ln查看.
ln srouce dest ln -s srouce dest 硬链接可以防止误删
硬连接的作用是允许一个文件拥有多个有效路径名，因为多个硬链接文件指向同一个索引节点.这样用户就可以建立硬连接到重要文件,以防止“误删”的功能.只删除一个链接并不影响索引节点本身和其它的链接，只有当最后一个链接被删除后，文件的数据块及目录的链接才会被释放。也就是说，文件才会被真正删除。
硬链接的两个限制
虽然系统有目录不能创建硬链接的限制,但是命令ln -d可以让超级用户对目录作硬连接，这说明系统限制对目录进行硬连接只是一个硬性规定，并不是逻辑上不允许或技术上的不可行。那么为什么要做出这个硬性规定呢?
第一,如果引入了对目录的硬连接就有可能在目录中引入循环，那么在目录遍历的时候系统就会陷入无限循环当中。可是符号连接不也可以引入循环吗？因为在linux系统中，每个文件(目录也是文件)都对应着一个inode结构，其中inode数据结构中包含了文件类型(目录，普通文件，符号连接文件等等)的信息，也就是说操作系统在遍历目录时可以判断出符号连接，既然可以判断出符号连接当然就可以采取一些措施来防范进入过大的循环了，系统在连续遇到8个符号连接后就停止遍历，这就是为什么对目录符号连接不会进入死循环的原因了。但是对于硬连接，由于操作系统中采用的数据结构和算法限制，目前是不能防范这种死循环的。
第二,文件的dentry结构主要包含了文件名,文件的inode号,指向父目录dentry结构的指针和其他一些指针,这里关键是那个指向父目录的指针;系统中所有的dentry结构都是按杂凑值存放在杂凑表中的，这里的杂凑算法很重要，它是取文件名和文件的父目录dentry结构的地址一起杂凑运算出杂凑值的。现在我们假设有两个目录 /a和/b，其中/b是我们通过ln -d命令建立起来的对/a的硬连接。这个时候内核空间中就会存在一个/a的dentry结构和一个/b的dentry结构，由上面的知识可知，/a和/b目录下面的每一个文件或目录都各自有对应的dentry结构(因为虽然/a目录下面的文件名没有改变，但是因为dentry结构有指向父目录dentry 的指针和计算杂凑值时考虑了父目录dentry结构的地址，这个时候dentry结构就分身乏术了),而且这种继承还会影响到所有子目录下面的文件，这样下来就会浪费很多系统空间了,特别是如果被硬连接的目录中存在大量文件和子目录的时候就更加明显了.
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/08/02/link-in-linux/ +
发表日期：2016/08/02 11:08
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 使用hexo+github搭建的博客,博客作为一个单独的github仓库存在,可是仓库中不包含你每篇博客的源文件。如果你换了一台机器想要更新博客或者想重新发布以前的博客,这就不好办了。我这里推荐一种云端备份的方法。
+ + +1 | $ git pull |
1 | $ git add . |
1 | $ hexo n "postName" # hexo new 新建文章 |
1 | $ git pull |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/08/10/backup-of-blog-with-hexo-and-github/ +
发表日期：2016/08/10 21:08
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍几种在Linux下清空文件的方法。
+ + +代码 :
+1 | #!/bin/bash |
运行结果 :
+1 | $ cat test.txt |
++使用这个方法文件其实并没有真正被清空，而是有一个空行。
+
代码 :
+1 | #!/bin/bash |
运行结果 :
+1 | $ cat test.txt |
+++
：是一个空命令，起到占位符的作用。这里被清空的文件不再有空行，实现真正意义的清空。
代码 :
+1 | #!/bin/bash |
运行结果 :
+1 | $ cat test.txt |
++ ++
/dev/null可以看作一个”黑洞”。所有写入它的内容都会丢失。从它那儿读取也什么都读不到。这里被清空的文件同样不再有空行，实现真正意义的清空。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/09/05/empty-file-in-shell/ +
发表日期：2016/09/05 11:09
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍几种Linux下通过Shell脚本进行浮点数计算的方法。
+ + +Bash Shell本身不具备处理浮点计算的能力, 如expr命令只支持整数运算 :
1 | #!/bin/bash |
运行结果 :
+1 | $ ./cal.sh |
使用bc进行处理。
代码 :
1 | #!/bin/bash |
运行结果 :
+1 | $ ./bc.sh |
+++
scale表示结果的小数精度。
使用awk进行处理。
代码 :
1 | #!/bin/bash |
运行结果 :
+1 | $ ./awk.sh |
使用bc :
使用awk :
++ +可以看出使用
+awk的效率更高,特别是运算次数比较大时。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/09/05/floating-point-operation-in-script/ +
发表日期：2016/09/05 14:09
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 现在3.5mm规格的耳机已经普遍使用，但是用户会发现一些国外厂家的耳机并不适用国产手机，下面就为大家科普一下，解开这个迷题。
+ + +美标也称为国际标准(CTIA)，从头开始分别是左声道/右声道/地线/MIC。目前在市场上最流行
+国标(OMTP)，从头开始分别是左声道/右声道/MIC/地线。
+
从上图可以发现美标和国标的差别就在于MIC和地线的位置不同，导致会出现在听音乐时只有伴奏没有人声，只有按住接听键才正常的现象。
+另外一个区别是，美标的中间三节隔离绝缘圈，一般是都是白色的。而国标为了有所分别，一般是都是黑色的，大部分耳机可以通过此方法来区别。
+美标耳机适用手机范围：苹果（全系列）、小米（全系列）、魅族（全系列）、索尼（全系列）、LG（全系列）、HTC官方产品、三星（咨询客服）、摩托罗拉部分机型（ME865）、联想W101、诺基亚Lumia和WP7系列、华为(C8812/U9200)、亿通T900等。
+国标耳机适用手机范围：诺基亚、索尼爱立信（全系列）、中兴（全系列）、步步高（全系列）、酷派（全系列）、HTC 非官方产品（A3380、A3360、T9188、A9188、Z510D）、三星旧产品（i8910、M3510C、M7500、F278、F700、F408、F490、G810、G818、G818E、i550W、8510、i560、S8000C、i8000、M2710C、i7500U、i9000、i6500U、F809、i8000、F859）、摩托罗拉XT531、联想A520/A750/P700、OPPO（全系列）等国产系列手机。
+++ +若发现国标/美标不适配自己的手机，某宝上面有转接线可以买，可以通过转换国标/美标。
+
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/09/20/standard-of-headphone/ +
发表日期：2016/09/20 11:09
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 当我们在Linux下需要处理json数据时,第一反应是用脚本编写一个工具,这样即耗时又不通用. 本文将介绍专门的命令行json处理工具jq.
+ + +Ubuntu用户可以直接使用下列命令安装:
+1 | $ sudo apt-get install jq |
也可以选择源码安装,当然最简单的方法是直接下载可执行文件,不过需要找到适配你系统的版本.
+详细的安装方法可以参考这里.
+首先构建一个基本的字符串作为示例 test.json:
+1 | { |
1 | $ cat test.json | jq '.name' |
1 | $ cat test.json | jq '.province[0]' |
keys用来提取json中的key元素:
+1 | $ cat test.json | jq 'keys' |
has用来判断是否存在某个key:
+1 | $ cat test.json | jq 'has("name")' |
若json串格式错误的话,可以直接使用jq运行,会报出具体错误.
+有了这个工具.你就可以直接在命令行或者shell脚本对json数据进行操作了.
+ +原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/10/10/jq/ +
发表日期：2016/10/10 10:10
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文主要介绍Linux下C调用静态库和动态库,使用的样例文件请点击这里.
+ + +welcome.c:
+1 | #include<stdio.h> |
++这是一个样例程序,打印一句话.
+
welcome.h:
+1 | #ifndef _WELCOME_H |
++为上一个文件的声明.
+
动态库和静态库二者的不同点在于代码被载入的时刻不同。
+静态库的代码在编译过程中已经被载入可执行程序,因此体积比较大。动态库(共享库)的代码在可执行程序运行时才载入内存，在编译过程中仅简单的引用，因此代码体积比较小。
+静态情况下,把库直接加载到程序中,而动态库链接的时候,它只是保留接口,将动态库与程序代码独立,这样就可以提高代码的可复用度，和降低程序的耦合度。
+静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在.
+生成静态库文件:
+1 | $ gcc -Wall -O2 -fPIC -I./ -c -o welcome.o welcome.c |
ar命令的参数如下:
+1 | 参数 意义 |
test-sta.c:
+1 | #include<stdio.h> |
编译:
+1 | $ gcc test-sta.c -o test-sta ./libwelcome.a |
运行:
+1 | $ ./test-sta |
生成动态库文件:
+1 | $ gcc -o2 -fPIC -shared welcome.c -o libwelcome.so |
其中:
- fPIC : 产生与位置无关代码,全部使用相对地址.
- shared : 生成动态库.
test-implicit.c:
+1 | #include<stdio.h> |
++和静态库一样,测试代码不需要包含导出函数的头文件.
+
编译:
+1 | $ gcc -o2 -Wall -L. -lwelcome test-implicit.c -o test-implicit |
查看test-implicit动态段信息,发现已经依赖libwelcome.so:
1 | $ ldd test-implicit |
若此时直接运行,会提示找不到动态库:
+1 | $ ./test-implicit |
可以通过下列三种方法解决:
+1 | # 方法一 修改环境变量 |
再次运行:
+1 | $ ./test-implicit |
test-explicit.c:
+1 | #include<stdio.h> |
编译:
+1 | $ gcc -ldl test-explicit.c -o test-explicit |
查看test-explicit动态段信息,没有发现依赖libwelcome.so:
1 | $ ldd test-explicit |
运行:
+1 | $ ./test-explicit |
++区别: 隐式调用在编译可执行程序时需要指定库文件的搜索路径，而显式调用编译可执行程序时不用加上.
+
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/10/10/use-dynamic-and-static-library/ +
发表日期：2016/10/10 10:10
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍在文本流中,读写整数的两个接口– int getw(FILE *fp)和int putw(int w, FILE *fp),并且与你分享改进后的更实用的接口– unsigned int get_uint(FILE *fp)和unsigned int put_uint(unsigned int i,FILE *fp).
我们都知道,数据在计算机内存中都是以二进制的形式存储的,大多数PC的存储方式为小端存储,关于大小端字节序的讨论请参考阮一峰的理解字节序. 如果想直接读写整数,并不是很方便,这里就为你介绍两个接口,需要注意的是这两个接口非ANSI标准函数.
+函数原型：
+1 | int getw(FILE *fp); |
函数功能：
+1 | 从fp所指向文件读取下一个整数. |
返回值：
+1 | 返回输入的整数,如果文件结束或者出错返回-1. |
函数原型：
+1 | int putw(int w, FILE *fp); |
函数功能：
+1 | 将整型w写进fp指向的文件. |
返回值：
+1 | 返回输出的整数,如果出错,则返回EOF. |
代码:
+1 | #include <stdio.h> |
结果为:
+1 | $ 2147483647 -2147483648 |
++注意: 函数参数的压栈顺序是从左到右的,所以最后一个参数
+getw(fp)在栈顶,第一个出栈执行.
由于上述两个接口支持的是int型,所以取值范围为-2147483648～2147483647.(此文认为int型都为4个字节).笔者需要使用这两个接口去读写文件的大小,负数无用处的,所以决定改装一下这两个函数,顺便探究一下这个函数的实现:
1 | unsigned int get_uint(FILE *fp) |
1 | unsigned int put_uint(unsigned int i,FILE *fp) |
++改进后取值范围为
+0~4294967295.
同理,你也可以将这两个接口改为支持 long long和unsigned long int等不同长度的整数类型.
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/12/06/getw-and-putw/ +
发表日期：2016/12/06 14:12
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将使用C语言编写一个可以判断你主机数据存储方式(大端和小端)的程序.
+ + +计算机硬件存储数据的方式有两种: 大端字节序(big endian) 和 小端字节序(little endian),两者的区别可以简单理解为:
+如现在有数 0x1234,则两者存储方式如下:
++既然大端字节序符合人类读写的习惯,那么为什么会有小端字节序呢？
+
因为大多数默认情况下计算机的电路先处理低位字节，效率比较高，因为计算都是从低位开始的。所以，计算机的内部处理都是小端字节序。但是，人类还是习惯读写大端字节序。所以，除了计算机的内部处理，其他的场合几乎都是大端字节序，比如网络传输和文件储存。
当然并不是所有的计算机处理器都是小端模式的,目前IBM和Freescale的一些处理器以及一些常见的单片机芯片等都是采用大端字节序存储数据.而市面上大部分CPU则是采用小端字节序,如intel等.
+本例都认为short占2个字节,不考虑可移植的情况.
+1 | #include <stdio.h> |
这里利用了union 中所有的数据成员共用一个空间，同一时间只能储存其中一个数据成员的特性.
首先分配了一个占2个字节的内存空间(union分配的空间需要容纳最大长度的数据成员),将0x0102赋予short型变量.
然后利用char数组,按一个字节的长度依次取出数据,然后利用上节介绍的大小端存储方式的不同进行判断.
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2016/12/07/big-little-endian/ +
发表日期：2016/12/07 11:12
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍UNIX网络编程中listen函数及其包裹函数。
1 | #include<sys/socket.h> |
目前listen函数仅为TCP服务器调用，主要完成两个任务：
socket函数创建的还未建立连接的主动套接字转换为被动(监听)套接字，使内核接受指向该套接字的连接。++tips：
+socket函数创建的套接字被默认为一个主动套接字，即该套接字为将调用connect函数发起连接的客户套接字。而listen函数导致该套接字从CLOSED状态转换为LISTEN状态。
历史上总是将backlog设为5，但已无法满足现在服务器的需求了，所以需要指定一个较大的backlog才能满足繁忙的需求。一种方法是使用一个常值，可是每次增长都需要重新编译，比较麻烦；另一种方法是设定默认值，然后允许通过命令行或环境变量覆盖默认值：
1 | #include<stdlib.h> |
这样就可以通过设置环境变量LISTENQ来动态配置backlog的大小。
++ +tips：
+backlog为0不代表就不会有客户连接到你的机器。如果不想让客户连接，请直接关闭该套接字。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/02/23/listen-in-unix/ +
发表日期：2017/02/23 17:02
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍SaaS，BaaS，PaaS和IaaS这四种云计算服务模式，并分析之间的联系和区别。
+ + +
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/03/23/introduction-to-four-service-of-cloud-computing/ +
发表日期：2017/03/23 14:03
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ Json有两种比较常用的数据类型：被{}包裹的对象（object），被[]包裹的数组（array）
从第三方API返回的json数据，存在一个key的值为空数组，可是经过decode和encode这两步操作后，这个key的值就变为空对象了：
1 | local cjson = require('cjson') |
输出：
+1 | after cjson encode: {"name":"answer","list":{}} |
cjson对于空的table，会默认处理为object，对于Lua本身，是无法区分空数组和空字典的（数组和字典融合到一起了），但是对于强类型语言(C/C++, Java等)，这时候就会出现问题，必须作容错处理
encode_empty_table_as_object方法1 | local cjson = require('cjson') |
输出：
+1 | after cjson encode: {"name":"answer","list":[]} |
dkjson库1 | local dkjson = require('dkjson') |
输出：
+1 | after cjson encode: {"name":"answer","list":[]} |
metatable将table标记为array1 | local cjson = require('cjson') |
输出：
+1 | after cjson encode: {"name":"answer","list":[]} |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/06/16/table-encode-as-array-or-object/ +
发表日期：2017/06/16 15:06
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 观看OpenResty 系列课程的学习笔记
+ + +高性能服务端的两个特点：
+参考资料：
+ +OpenResty = Nginx + LuaJIT（LuaJIT虚拟机嵌在Nginx worker中）
lua_code_cache：lua代码缓存，默认开启，支持set_by_lua_file和content_by_lua_file等指令和lua模块，关闭后方便开发（不用重启Nginx），生产环境建议开启（影响性能）
content_by_lua_file：指定要执行的lua文件
运行时的错误日志保存在logs/error.log中
nginx.conf示例片段：
1 | location = /api/random { |
random.lua：
1 | local args = ngx.req.get_uri_args() --max is 100，set 0 to unlimit |
++Tips： 不要使用
+lua API（阻塞），要用ngx lua API（非阻塞）
++Tips： 数据库操作的代码逻辑看上去是同步的，但是内部实现是异步的
+
主要有lua-resty-redis和lua-resty-mysql
+worker共享，需要锁操作key个数，单个worker使用，内存使用翻倍缓存失效风暴：在缓存超时时间触发的瞬间，所有的并发请求都同时执行数据库查询操作，数据库压力瞬间变大，下次请求又全部进入缓存，压力瞬间变小，出现两个极值。可以使用lua-resty-lock对数据库查询操作加锁，使数据库查询只进行一次
+FFI：LuaJIT的一个库，可以在LuaJIT中调用C的数据结构和外部C函数。如random.lua
第三方模块：放在/openresty/lualib/resty目录下。
ngx.location.capture和ngx.location.capture_multi：在一个location内部，对另一个location进行请求，因为这不是http请求，是C级别的调用，所以有开销小的优点; 同时可以降级服务（某一个非关键服务down掉，可以继续使用），开放给前端就一个api接口即可，在这个api接口内做多个子查询，不需要前端调用多个api进行查询，避免由于某一个api服务挂掉而导致阻塞
1 | location = /api/test_parallels { |
这个是Nginx和OpenResty独有的概念，不同的阶段有不同的处理行为，可参考执行阶段概念
更改conf后，检查conf文件是否正确：nginx -t -c [conf]
重启：nginx：nginx -s reload -p [path]
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/06/20/note-of-openresty-study/ +
发表日期：2017/06/20 17:06
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 对UNIX下的五种常见IO模型分析，帮助理解
+ + +以读数据操作为例：
+UNIX下共有五种常见的IO模型：
下面以recvfrom接口举例
默认情况下，所有的套接字都是阻塞的
调用recvfrom接口，进程在IO操作的两个阶段都会阻塞，直到最终数据拷贝到用户空间或者过程中出现错误才会返回，进程在阻塞状态下是不占用CPU资源的
++最常见的错误是发生系统中断，此时需要重读，可参考这里
+
可以通过fcntl(sockfd,F_SETFL,O_NONBLOCK)将套接字设置成非阻塞
调用recvfrom接口，无论内核缓冲区是否有可用数据，进程都会立即返回，所以在IO操作的第一阶段是非阻塞的; 若无数据可用，内核将errno设置为为EWOULDBLOCK或者EAGAIN，进程可以使用轮询的方法，保证内核在数据准备好时，能立即拷贝到用户空间; 若有则立即将数据拷贝到用户空间，进程在数据拷贝到用户空间即IO操作的第二阶段是阻塞的;
++非阻塞IO过于消耗CPU时间，将大部分时间用于轮询
+
多路复用系统调用：select,poll和epoll，其中windows平台不支持poll和epoll，使用方法可以参考I/O 多路复用之select、poll、epoll详解和Linux select/poll和epoll实现机制对比
调用select，等待内核数据准备，所以IO操作的第一个阶段，进程是阻塞的，不过是阻塞在多路复用系统调用上，而不是IO系统调用上; 当select返回套接字可读条件时，再调用recvfrom将数据从内核拷贝到用户空间，IO操作的第二阶段，进程是阻塞的
多路复用IO和阻塞IO，在IO操作的两个阶段都是阻塞的，不过多路复用IO使用了两个系统调用，而阻塞IO只使用了一个，所以在连接数不是很多的情况下，阻塞IO可能性能更佳; 多路复用IO的优势在于可以同时监控多个用于IO的文件描述符。
+++多线程中的阻塞IO，与多路复用IO极为相似
+
调用sigaction等系统调用安装信号处理函数，并立即返回，所以IO操作的第一阶段，进程是非阻塞的; 当内核数据准备好时，内核会产生一个信号，通知进程将数据从内核拷贝到用户空间，IO操作的第二阶段，进程是阻塞的
++使用方法：IO的多路复用和信号驱动
+
异步IO有一组以aio开头的系统调用，使用方法可参考Linux AIO机制
调用异步IO系统调用，给内核传递描述字、缓冲区指针、缓冲区大小（与read相同的三个参数）、文件偏移（与lseek类似），告诉内核当整个操作完成时如何通知我们，并立即返回，在IO操作的两个阶段，进程都不阻塞
++知乎上有一个比较生动的例子可以说明这几种模型之间的关系。
+
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/06/27/io-model/ +
发表日期：2017/06/27 16:06
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ ARM 平台下GCC编译相关介绍，待补充
ARM处理器架构，通过选项-march指定，如-march=armv7-a，常见的有
armv5tearm9系列使用该架构 armv6arm11系列使用该架构armv7-acortex-a系列使用该架构，如cortex-a5、a7、a8、a9、a12、a15armv8cortex-a系列使用该架构，如cortex-a53、a57、a72指令集，通过选项-m指定，如-mthumb，常见的有
thumbthumb-2thumb指令集进行了扩充，增加了一些32位指令，改善thumb指令集的性能armarm架构，性能高浮点运算的类型，通过选项-mfloat-abi指定，如-mfloat-abi=hard，有三种类型
softFPU的CPUsoftfpsoft兼容hardsoftfp的区别在于调用接口的规则不同硬浮点指令的类型，通过选项-mfpu指定，如-mfpu=neon，常用的有两种
vfpvfpv2应用于armv5te, armv6架构中的浮点计算指令集，vfpv3和vfpv4应用于部分armv7a架构中的浮点计算指令集neoncortex-a系列处理器，性能好原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/08/04/gcc-compilation-of-arm-articles/ +
发表日期：2017/08/04 16:08
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 条件变量是Linux线程同步的一种机制，与互斥量一起使用时，允许线程以无竞争的方式等待特定条件的发生
+ + +[TOC]
+1 | #include <pthread.h> |
注意：
+EBUSYLinux在实现条件变量时，并没有为条件变量分配资源，所以在注销一个条件变量时，只需要注意该变量是否仍有等待线程即可1 | #include <pthread.h> |
执行过程如下：
+CPU时间) +++
pthread_cond_timedwait只是多了一个等待超时时间，通过timespec指定，超时返回错误ETIMEDOUT
1 | #include <pthread.h> |
pthread_cond_signal至少能唤醒一个等待该条件的线程pthread_cond_broadcast则能唤醒等待该条件的所有线程++需要注意的是，一定要在改变条件状态以后再给线程发信号
+
示例代码可参考我的github，由于篇幅原因，不在此贴出
+条件变量实质是利用线程间共享的全局变量进行同步的一种机制
+示例中的相关代码
+1 | pthread_mutex_lock(&(test->mut)); |
互斥量是用来保护条件test->condition在读取时，它的值不被其它线程修改，如果条件成立，则此线程进入等待条件的线程队列，对互斥量进行解锁并开始等待
如上面的代码所示，使用while对条件进行判断的原因如下：
pthread_cond_wait可能存在意外返回的情况，则此时条件并没有被更改，需要继续等待。++造成意外返回的原因是
+Linux中带阻塞功能的系统调用都会在进程收到signal后返回
示例代码：
+情况一：先唤醒
+1 | pthread_mutex_lock(&(test->mut)); |
情况二：先解锁
+1 | pthread_mutex_lock(&(test->mut)); |
两种情况各有缺点：
+原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/12/15/condition-variables-of-thread-synchronization/ +
发表日期：2017/12/15 22:12
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将对Speex相关的概念进行介绍
+ + +[TOC]
+Speex编解码器是一款开源且免费的语音编解码器，遵循BSD协议，为分封网络（packet network）和网络电话（VoIP）而设计，支持文件的压缩
+++为网络电话而不是移动电话而设计，意味着Speex对数据丢失具有鲁棒性，但是对数据包损坏不鲁棒，在VoIP中的数据包要么完整到达，要么不能到达
+
Speex选用CELP（码激励线性预测编码）编码技术，在高比特率和低比特率都稳定可靠，复杂性适度并且占用内存较少
+采样率是每秒钟采集到的信号样本数，单位是Hertz（Hz），Speex为三种不同的采样率而设计：8kHz（窄带），16kHz（宽带）和32kHz（超宽带）
+在对语音信号编码时，比特率定义为单位时间内的比特数，单位是比特每秒（bps）或通常的千比特每秒（kbps）
+++注意千比特每秒（kbps）和千字节每秒（kBps）的区别。
+
Speex是有损的编解码器，意味着压缩率以输入语音信号的保真度为代价，质量越高，压缩后的比特率越大，音质也越好
Speex可以控制质量和比特率之间的折中，大多数时间由一个范围在0到10之间的质量参数控制
++在不变比特率（CBR）中，质量参数是一个整数； 在可变比特率（VBR）中，质量参数是一个浮点数。
+
Speex允许编码器拥有可变的复杂度，通过一个范围在1到10之间的整数控制搜索的执行来实现，复杂度越高，压缩率越高，CPU使用率越高，音质越好，类似于gzip和bzip2压缩工具的-1到*-9选项
正常使用情况下，复杂度为1的噪声等级比复杂度为10的噪声等级高1到2个dB，但复杂度为10的CPU要求比复杂度为1的高5*倍。
++实际应用中，最好的折中是复杂度2到4，但在编码非语音声音如DTMF声调时更高的复杂度经常被用到
+
可变比特率（VBR）允许编解码器自适应的根据待编码音频的“难度”动态地改变比特率，如元音和高能瞬态变化的声音需要高比特率以获得好的质量； 但是摩擦音（如s，f）用低比特率就能充分编码
+平均比特率解决了VBR中的一个问题，它动态地调整VBR质量以获得指定的比特率，因为质量和比特率是实时调整的，ABR的全局质量比正好达到目标平均比特率的VBR编码质量稍微差些。
+VAD检测待编码的音频是语音还是无声/背景噪声，VBR编码中默认激活
+++Speex检测出非语言段并仅使用足够复现背景噪声的比特率进行编码，这叫“柔化噪音生成”（CNG）。
+
断续传输是VAD/VBR的附加操作，当背景噪声平稳时会完全停止传输
+知觉增强是解码器的一部分，当被启用时，能减少编解码过程中产生的噪声或失真的知觉
+++在大多数情况下，知觉增强会带来声音客观上的偏离（如仅考虑SNR），但最后仍听起来更好（主管增强）
+
每一个语音编解码器在传输中都会引入延时，对于Speex，延时等于帧长加上处理每一帧需要前几帧的数量
+++在窄带操作中延时为30ms，在宽带操作中延时为34ms，这不包括编解码帧时的CPU时间
+
Speex编解码器有以下特性
+预处理器在对音频编码前对音频进行预处理，有三个主要功能
+当通过UDP（User Datagram Protocal，用户数据报协议）或RTP（Real Time Protocal，实时传输协议）传输声音（或其他任何内容）时，数据包可能丢失，不同延时到达，甚至乱序，抖动缓冲器的作用是对数据包进行重排序并保存在足够长的buffer（但有一定限度）里，然后将数据包发送去解码
+在任何免提式通信系统中（下图），远端的语音在本地扬声器播放时，经过在房间里传播后又会被麦克风录音，如果将麦克风录音直接又发送到远端，则远端的用户将会听到他自己的回声
声学回声消除器就是为了在将录音发送到远端前消除声学回声，提高了远端接收的语音质量
重采样指转换音频的采样率，在任意采样率间进行转换（采样率必须是有理数），能控制质量和复杂度的折中，可用于能混合不同采样率流，支持声卡不支持的采样率，能转码等
+原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2017/12/29/speex/ +
发表日期：2017/12/29 15:12
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 有时候程序会异常退出而不带任何日志，此时就可以使用core文件进行分析，它会记录程序运行的内存，寄存器，堆栈指针等信息
通常在Linux下遇到程序异常退出或者中止，我们都会使用core文件进行分析，其中包含了程序运行时的内存，寄存器，堆栈指针等信息，格式为ELF，可以理解是程序工作当前状态转储成一个文件，通过工具分析这个文件，我们可以定位到程序异常退出或者终止时相应的堆栈调用等信息，为解决问题提供帮助。
查看当前core文件的状态
1 | $ ulimit -a |
打开生成开关
+1 | ulimit -c unlimited |
对core文件的大小进行限制，单位为blocks，一般1 block=512 bytes，设置太小可能导致不会生成文件
1 | $ ulimit -c 1024 |
关闭生成开关
+1 | ulimit -c 0 |
++上面对
+core文件的操作仅对当前生效，若需要永久生效，则要将相应操作写入/etc/profile
core文件默认生成在程序的工作目录，可以对生成路径进行设置，需要保证对对应目录有足够空间并具有写权限
1 | echo /MyCoreDumpDir/core.%e.%p > /proc/sys/kernel/core_pattern |
其中命名使用的参数列表
+1 | %p - insert pid into filename # 添加 pid |
+++
/proc/sys/kernel/core_uses_pid这个文件的值若为１，则无论是否配置%p,最后生成的core文件都会添加pid
可以使用gdb对core文件进行调试，编译时需要带上-g选项
1 | $ gdb a.out |
如需要在PC上调试嵌入式设备产生的core文件，则需要选取相应平台的gdb工具，并在进入gdb后设置符号文件的位置
1 | $ xxx-xxx-gdb a.out |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2018/03/07/usage-of-core-in-linux/ +
发表日期：2018/03/07 16:03
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 学习使用cJSON过程的一些发现和总结，不涉及具体的函数
+ + +cJSON是一个快速，高性能的json解析器，由C语言编写，仅包含cJSON.c和cJSON.h两个文件，不支持跨平台；跨平台推荐纯lua写的dkjson
cJSON结构体的组成：
1 | typedef struct cJSON { |
其中
+next指向链表中下一个兄弟节点，prev指向本节点前一个节点child节点只有对象和数组有，并且child节点是双向链表的头节点，child的prev一般为NULL，不指向任何节点，双向链表的最后一个兄弟节点的next是无指向的type取值有Null/True/False/Number/String/Array/Object，这些值类型都在cJSON.h中通过宏定义了String类型节点有valuestring ，Number类型节点有valueint和valuedoublestring表示节点的名称，所有的节点都是一个链表，都具有string值+++
cJSON默认所有值都为0，除非额外为其赋有意义的值
cJSON使用树结构存储JSON的各个节点，而这个树结构是使用双向链表实现的(实线表示节点间有真实的引用关系，而虚线表示逻辑上的引用关系)：
下面举例说明：
+1 | { |
name和format节点组成一个链表，type、width、height、interlace和frame rate节点组成一个链表Object和子节点namename、节点值Jack ("Bee") Nimble和兄弟节点formatformat节点包含节点类型Object、节点名称format和子节点typetype节点包含节点类型String、节点名称type、节点值rect和兄弟节点widthwidth节点包含节点类型Number、节点名称width、节点值1920和兄弟节点heightheight节点包含节点类型Number、节点名称height、节点值1080和兄弟节点interlace interlace节点包含节点类型False、节点名称interlace和兄弟节点frame rateframe rate节点包含节点类型Number、节点名称frame tate和节点值25cJson分为自动和手动两种使用方式：
cJSON使用默认的malloc和free函数管理内存，在cJSON中，每个节点都是malloc而来，每个节点的string和valuestring也是malloc而来，使用cJSON_Delete函数可以递归释放JSON树中malloc的节点内存和字符内存，使用cJSON_Print函数后，则需要手动释放cJSON_Print函数分配的内存，避免内存泄露cJSON提供了钩子函数来帮助用户自定义内存管理函数，如果不设置，这默认为malloc和free1 | struct cJSON_Hooks js_hook = {xxx_malloc, xxx_free}; |
cJSON序列化就是把cJSON输出，有两种形式：
char *cJSON_Print(cJSON *item);char *cJSON_PrintUnformatted(cJSON *item);需要注意的是cJSON采用了预先将要输的内容全部以字符串形式存储在内存中，最后输出整个字符串的方法，而不是边分析json数据边输出，所以对于比较大的json数据来说，内存就是个问题了
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2018/05/03/cjson/ +
发表日期：2018/05/03 16:05
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 代码覆盖率测试反映了测试的广度与深度，量化了测试和开发质量，是十分有必要的，业界目前有针对各种语言的覆盖率测试工具，本文主要介绍C/C++相关的覆盖率测试工具Gcov
Gcov是一个测试覆盖程序，是集成在GCC中的，随GCC一起发布
基本块指一段程序的第一条语句被执行过一次后，这段程序中的每一跳语句都需要执行一次，称为基本块，因此基本块中的所有语句的执行次数是相同的，一般由多个顺序执行语句后边跟一个跳转语句组成
+从一个BB到另外一个BB的跳转叫做一个ARC,要想知道程序中的每个语句和分支的执行次数，就必须知道每个BB和ARC的执行次数
如果把BB作为一个节点，这样一个函数中的所有BB就构成了一个有向图，要想知道程序中的每个语句和分支的执行次数，就必须知道每个BB和ARC的执行次数，根据图论可以知道有向图中BB的入度和出度是相同的，所以只要知道了部分的BB或者ARC大小，就可以推断所有的大小，这里选择由ARC的执行次数来推断BB的执行次数，所以对部分ARC插桩，只要满足可以统计出来所有的BB和ARC的执行次数即可
测试程序首先进行编译预处理，生成汇编文件，并完成插桩，插桩的过程中会向源文件的末尾插入一个静态数组，数组的大小就是这个源文件中桩点的个数，数组的值就是桩点的执行次数，每个桩点插入3~4条汇编语句，直接插入生成的*.s文件中，最后汇编文件经过汇编生成目标文件，在程序运行过程中桩点负责收集程序的执行信息
测试代码如下：say.c:
1 | #include <stdio.h> |
main.c
1 | #include <stdio.h> |
添加-fprofile-arcs -ftest-coverage -fPIC编译参数编译程序，生成可执行程序和*.gcno文件，里面记录了行信息和程序流图信息：
1 | $ gcc -fprofile-arcs -ftest-coverage -fPIC -O0 say.c main.c |
运行可执行文件，生成*.gcda在默认生成在相应*.o文件目录，里面记录了*.c文件中程序的执行情况，包括跳变次数等:
1 | $ ./a.out |
可以通过设置环境变量GCOV_PREFIX=/xxx/xxx和GCOV_PREFIX_STRIP=x来改变路径，其中GCOV_PREFIX_STRIP表示去掉源代码路径中的前几级，默认为0，比如源代码路径为/a/b/c/d.c，GCOV_PREFIX_STRIP=2，则实际使用的路径是c/d.c，如果GCOV_PREFIX=/e/f，则.gcda实际存放的路径是/e/f/c/d.gcda
针对某一个文件的执行情况，可以通过如下命令生成报告，并创建*.gcov文件：
1 | $ gcov -a main.c |
常用选项，更多可参考Invoking gcov：
+1 | -b：分支覆盖 |
gcov只统计宏调用出现的那一行*.gcno与*.gcda需要匹配，两个文件是有时间戳来记录是不是匹配的-lgcovgcov生成的报告分散在各个源码文件所对应的*.gcov文件中，难以汇总分析，并且可视化效果较差，所以需要转化成可视图形化报告，有lcov或gcovr两个工具可以完成，两者功能基本相同，本文主要介绍gcovr，是一个用Python编写的开源软件，大小只有几十KB，安装参见官网
代码覆盖率
+1 | $ gcovr -r . |
报告展示程序运行后覆盖了80%的代码
分支覆盖率
+1 | $ gcovr -b -r . |
报告展示了在main.c中有一个分支没有执行到
1 | $ gcovr --xml-pretty -r . |
1 | $ gcovr -r . --html -o xxx.html |
可以发现添加--html参数后，可以生成html文件，用浏览器打开，如下图：
还可以添加--html-details选项，为每个代码文件单独生成html
1 | $ gcovr -r . --html --html-details -o xxx.html |
可以发现多了xxx.main.c.html和xxx.say.c.html，用浏览器打开xxx.html，如下图：
文件名较之前带上了下划线，单击文件名，可以看到具体的代码覆盖情况，如下图：
其它功能，如Filters等，可以参考官方文档
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2018/09/25/coverage-of-code/ +
发表日期：2018/09/25 18:09
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文是对之前Git速查手册的更新，增加了一些这段时间使用到的命令。
+ + +笔者使用的是v2.1.0，推荐大家使用v1.8以上的版本。 查看git版本：
+1 | $ git --version |
配置命令git config分为三个级别：
1 | --system : 系统级,位于 /etc/gitconfig . |
首先需要删除global用户信息,防止不同git软件之间的冲突：
+1 | $ git config --global --unset user.name |
设置用户信息.若同时使用gitlab和github,推荐配置local用户信息：
+1 | $ git config --local user.name "username" |
git支持https和ssh等协议.https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，而ssh支持的原生git协议速度最快。
检查本机SSH公钥:
1 | $ ls ~/.ssh |
若存在,则将id_rsa.pub添加到github的SSH keys中。若不存在,则生成:
1 | $ ssh-keygen -t rsa -C "your_email@youremail.com" |
当ssh配置完成后，再次检查ssh连接情况：
+1 | $ ssh -T git@github.com |
若出现上述信息，则表示设置成功。
若使用https访问, 则进行如下配置,并且设置超时时间避免重复输入密码：
1 | $ git config --global http.sslverify false |
设置可视化diff和merge工具, linux系统上推荐使用meld或者diffuse：
+1 | $ git config --global diff.tool meld |
保存用户名,密码, 避免每次pull/push操作都需要手动输入：
1 | $ git config --global credential.helper store |
设置颜色,利于使用：
+1 | $ git config --global color.ui.true |
设置别名：
+1 | $ git config --global alias checkout co |
++上面的命令将
+checkout设置为别名co。
最后,查看一下所有的设置：
+1 | $ git config --local --list |
工作区就是你的本地仓库文件夹,不过其中的.git目录不属于工作区,而是版本库。里面存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
现在来解释一下前面的添加和提交操作：
git add把文件添加进去，实际上就是把文件修改添加到暂存区；git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。获取远程仓库：
+1 | $ git clone git@github.com:USERNAME/repo.git |
将本地的仓库添加到远程：
+1 | $ cd repo |
+++
origin就是一个名字，是git为你默认创建的指向这个远程代码库的标签。
添加修改:
+1 | $ git add <filename> |
提交修改:
+1 | $ git commit -m "commit message" |
+++
commit message的填写可以参考写好 Git Commit 信息的 7 个建议。am将添加和提交合并为一步,但只对本来就存在的文件有效。
推送修改：
+1 | $ git push -u origin <feature-branch-name> |
+++
-u选项可以将本地分支与远程分支关联,下次git pull操作时可以不带参数.具体参见这里。
查看远程仓库：
+1 | $ git remote -v |
fork后同步上游仓库的更新：
+1 | # 第一次需要添加上游仓库 |
引用公共代码：
代码引用在git上有两种方式：submodule和subtree，推荐使用subtree方式。
1 | # 第一次初始化 |
查看标签 ：
+1 | $ git tag |
创建标签 ：
+1 | $ git tag -a <tagname> -m "tag message" # 创建标签在当前最新提交的commit上 |
推送标签到远程：
+1 | $ git push origin <tagname> # 推送一个本地标签 |
删除标签：
+1 | $ git tag -d <tagname> # 删除一个本地标签； |
查看当前仓库状态:
+1 | $ git status |
查看文件更改：
+1 | $ git difftool <filename> |
查看提交历史:
+1 | $ git log |
撤销工作区Tracked files的修改：
1 | $ git checkout -- <filename> |
撤销工作区Untracked files的修改：
1 | ##### |
回退版本区(git commit)和暂存区(git add)，不删除工作空间代码：
1 | $ git reset --mixed HEAD^ # --mixed为默认参数 |
回退版本区(git commit)，暂存区(git add)不回退，不删除工作空间代码：
1 | $ git reset --soft HEAD^ |
回退版本区(git commit)和暂存区(git add)，并删除工作空间代码(不包括Untracked files)，执行后直接恢复到指定<commit-id>状态：
1 | $ git reset --hard <commit-id> |
+++
HEAD表示当前版本，HEAD^表示上个版本，HEAD^^表示上上个版本，上100个版本可以表示为HEAD~100以此类推。
回退版本后，若需要返回原来的版本，会发现找不到未来的commit id，则需要查看操作命令历史进行查找：
1 | $ git reflog |
从版本库删除文件：
+1 | $ git rm <filename> |
若你的代码已经push到线上，则推荐使用下面这个命令回滚：
1 | $ git revert <commit-id> |
+++
revert是用一次新的commit来回滚之前的commit，更安全;reset则是直接删除指定的commit，若直接push会导致冲突。
查看所有分支，有*标记的是当前分支：
1 | $ git branch -a |
创建本地分支：
+1 | $ git branch <newbranch> |
创建并切换本地分支：
+1 | $ git checkout -b <newbranch> |
从标签创建分支：
+1 | $ git branch <branch> <tagname> |
推送新建本地分支到远程：
+1 | $ git push -u origin <remote-branch-name> |
删除本地分支：
+1 | $ git branch -d <branch> |
++若当前分支因为有修改未提交或其它情况不能删除，请使用
+-D选项强制删除。
删除远程分支(三种方法)：
+1 | $ git push origin --delete <remote-branch-name> |
清除无用的分支：
+1 | $ git remote prune origin |
++说明：remote上的一个分支被其他人删除后，需要更新本地的分支列表。
+
获取远程分支到本地已有分支：
+1 | $ git branch --set-upstream <local-branch> origin/branch |
获取远程分支到本地并新建本地分支：
+1 | $ git checkout -b <local-branch> <remote-branch> |
同步当前分支的更新，使用git pull并不保险：
1 | # 下载最新的代码到远程跟踪分支, 即origin/<branch-name> |
同步其它分支的更新，本例拉取master分支更新：
1 | $ git fetch origin master |
查看某个<commit id>属于哪个分支:
1 | $ git branch -a --contains <commit id> |
当你需要切换分支时,若当前工作区还有些修改没有完成,又不适合提交的,操作切换分支是会提示出错的.这时就需要将这些修改暂存起来:
+1 | $ git stash save "message" |
查看:
+1 | $ git stash list |
恢复:
+1 | $ git stash pop [--index] [stash@{num}] |
+++
--index表示不仅恢复工作区,还会恢复暂存区;num是你要恢复的操作的序列号,默认恢复最新进度.
删除进度:
+1 | $ git stash drop [stash@{num}] # 删除指定进度 |
1 | $ git branch -d <branch-name> |
查看git相关文件占用空间：
1 | $ git count-objects -v |
寻找大文件ID
1 | $ git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 |
++输出的第一列是文件
+ID，第二列表示文件（blob）或目录（tree），第三列是文件大小，此处筛选了最大的10条
获取文件名与ID映射
1 | $ git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')" |
从所有提交中删除文件
+1 | $ git filter-branch --tree-filter 'rm -rf xxx' HEAD --all |
清理.git目录:
1 | $ git gc --prune=now |
++tips: 在执行
+push操作时，git会自动执行一次gc操作，不过只有loose object达到一定数量后才会真正调用，建议手动执行。
由于git在存储二进制文件时效率不高,所以需要借助第三方组件。
+当你的仓库中有一些文件，类似密码或者数据库文件不需要提交但又必须放在仓库目录下，每次git status都会提示Untracked，看着让人很不爽，提供两种方法解决这个问题
在代码仓库目录创建一个.gitignore文件，编写规则如下：
1 | tmp/ # 忽略tmp文件夹下所有内容 |
在用户目录创建一个.gitignore_global文件，编写规则同.gitignore，并修改~/.gitconfig
1 | [core] |
如果添加的忽略对象已经Tracked，纳入了版本管理中，则需要在代码仓库中先把本地缓存删除,改变成Untracked状态
1 | $ git rm -r --cached . |
+ ++
1 | $ git rebase -i [git-hash| head~n] |
++其中
+git-hash是你要开始进行rebase的commit的hash，而head~n则是从HEAD向前推n个commit
1 | git filter-branch --commit-filter ' |
查看帮助：
+1 | $ git --help |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2019/02/12/git-help-v2/ +
发表日期：2019/02/12 12:02
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 分享屏蔽静态库接口的一种方法.
+ + +hello.c:
1 | #include <stdio.h> |
hello.h:
1 | #ifndef __HELLO__H |
bye.c:
1 | #include <stdio.h> |
bye.h:
1 | #ifndef __BYE__H |
编译时使用-fvisibility=hidden,可以默认将符号隐藏;需要对外的符号使用__attribute__ ((visibility ("default")))修饰即可:
1 | $ gcc -fvisibility=hidden -I. -c hello.c -o hello.o |
其中hello()未被隐藏,bye()是被隐藏的.
将生成的两个.o文件重定位到libt.o中:
1 | $ ld -r hello.o bye.o -o libt.o |
1 | $ strip --strip-unneeded libt.o |
1 | $ objcopy --localize-hidden libt.o libt_hidden.o |
1 | $ ar crv libt.a libt_hidden.o |
hello()test1.c:
1 | #include "hello.h" |
编译并运行
+1 | $ gcc -I. test1.c -L. -lt -o test |
bye()test2.c
+1 | #include "bye.h" |
编译并运行
+1 | $ gcc -I. test2.c -L. -lt -o test |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2019/04/13/hide-symbol-of-static-library/ +
发表日期：2019/04/13 14:04
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文介绍链接过程中sysroot的作用。
做过交叉编译的同学们，一定对下面这个错误十分熟悉吧：
+1 | /cross-compiling/ld: cannot find crt1.o: No such file or directory |
在我们的pc上，这两个文件一般在/usr/lib或者/usr/lib32中，通过gcc -print-search-dirs可以看到这两个路径默认就在库的搜索路径中，所以在pc上编译程序时不存在链接器找不到crt1.o和crti.o的问题。
+++
crt1.o负责应用程序的启动，其中包含了程序的入口函数_start以及两个未定义的符号__libc_start_main和main，由_start负责调用__libc_start_main初始化libc，然后调用我们源代码中定义的main函数，crti.o负责辅助启动这些代码。
下面我们使用交叉编译工具链来查看库的搜索路径/cross-compiling/gcc -print-search-dirs，发现crt1.o和crti.o的所在目录并不在库的搜索路径中，所以会出现上述的问题。
下面就需要sysroot出场了。sysroot被称为逻辑根目录，只在链接过程中起作用，作为交叉编译工具链搜索库文件的根路径，如配置--sysroot=dir，则dir作为逻辑根目录，链接器将在dir/usr/lib中搜索库文件。
++只有链接器开启了–with-sysroot选项，–sysroot=director才生效
+
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2019/04/26/what-is-sysroot/ +
发表日期：2019/04/26 17:04
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文通过分析源码，深究GLIBC中strtok和strtok_r函数的实现原理和使用过程中的注意事项。
1 | #include <string.h> |
strtok以包含在delim中的字符为分割符，将str分割成一个个子串；若str为空值NULL，则函数内部保存的静态指针（指向上一次分割位置后一个字节）在下一次调用中将作为起始位置。strtok_r功能同strtok，不过其将strtok函数内部保存的指针显示化，通过saveptr输入，以saveptr作为分割的起始位置。str: 待分割的源字符串delim: 分割符字符集合saveptr: 一个指向char *的指针变量，保存分割时的上下文'/0’，所以可以成功打印子串的内容1 | #include <stdio.h> |
1 | char str[12] = "hello,world\0"; |
1 | $ str before strtok: hello,world |
如上实验，str的值，在对其做strtok操作之后，发生了变化，分割符之后的内容不见了。事实上，strtok函数是根据输入的分割符（即,），找到其首次出现的位置（即world之前的,），将其修改为'/0’。
因为strtok函数会修改源字符串，所以第一个参数不可为字符串常量，不然程序会抛出异常。
NULL1 | char str[12] = "hello,world\0"; |
1 | $ hello |
在第一次提取子串时，strtok用一个指针指向了分割符的下一位，即’w’所在的位置，后续的提取给strtok的第一个参数传递了空值NULL，strtok会从上一次调用隐式保存的位置，继续分割字符串。
1 | char str[12] = "hello,world\0"; |
1 | $ he |
由上可见，strtok函数在分割字符串时，不是完整匹配第二个参数传入的分割符，而是使用包含在分割符集合中的字符进行匹配。
1 | char str[13] = ",hello,world\0"; |
1 | $ hello |
如上所示，若首字符为分割符，strtok采用了比常规处理更快的方式，直接跳过了首字符。
strtok为不可重入函数，使用strtok_r更灵活和安全strtok函数在内部使用了静态变量，即用静态指针保存了下一次调用的起始位置，对调用者不可见；strtok_r则将strtok内部隐式保存的指针，以参数的形式由调用者进行传递、保存甚至是修改，使函数更具灵活性和安全性；此外，在windows也有分割字符串安全函数strtok_s。
strtok.c:
+1 | /* Copyright (C) 1991-2018 Free Software Foundation, Inc. |
strtok_r.c:
+1 | /* Reentrant string tokenizer. Generic version. |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2019/05/21/man-strtok/ +
发表日期：2019/05/21 15:05
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将展示，如何将一个二进制文件(如图片、音频等)作为目标文件中的一个段，该技巧主要应用在一些无文件系统的平台。
+ + +本次的实验场景为i386:x86-64 GNU/Linux，测试音频为nhxc.wav，测试程序为bin2obj.c。
生成目标文件
+1 | $ gcc -c bin2obj.c -o bin2obj.o |
查看该平台ELF文件相关信息
1 | $ objdump -x bin2obj.o |
由上可知，文件格式为elf64-x86-64，CPU架构为architecture。
首先通过objcopy --help选项查看相关参数的意义:
1 | $ objcopy --help |
由上可知，-I选项指定输入文件的格式，-O指定输出文件的格式，在supported targets中选择对应的格式；-B是指定目标文件的架构i386:x86-64，即上文objdump -x命令查询的architecture。
转换：
+1 | $ objcopy -I binary -O elf64-x86-64 -B i386:x86-64 nhxc.wav audio.o |
查看转换后生成的目标文件：
+1 | $ objdump -x audio.o |
可以看到file format、architecture信息与bin2obj.o的相同，_binary_nhxc_wav_start指向音频内容的起始地址，_binary_nhxc_wav_end指向音频内容的结尾地址，_binary_nhxc_wav_size指向文件大小的存储地址。
+++
_binary_*_start/end/size，*是二进制文件的文件名及后缀名。
1 | #include <stdio.h> |
通过_binary_nhxc_wav_start和_binary_nhxc_wav_size两个符号，读取音频文件。
编译并运行：
+1 | $ gcc -c bin2obj.c -o bin2obj.o |
比对写入的文件out.wav与原始文件nhxc.wav，完全一致：
1 | 155e62d81e84fa7493fefe82223bcc2a nhxc.wav |
查看audio.o：
+1 | $ hexdump -C audio.o | head -n 5 |
如程序输出，ELF文件头部信息结构体为64字节，而转换生成的目标文件中，音频内容始于0x40字节偏移（wav头始于RIFF，可以参考wav文件解析），而0x40正是十进制的64。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2019/07/24/binary-to-object-file/ +
发表日期：2019/07/24 11:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文记录工作中遇到的clone大仓库失败的解决过程，以下问题与解决方案均基于https访问。
从web端查看仓库大小，大约1.5G左右，首先直接执行git clone，报错如下：
1 | remote: Counting objects: 10994, done. |
在增大postBuffer的同时，关闭ssl认证：
1 | $ git config --global http.postBuffer 2048000000 # 设置为2G |
设置成功后，重新clone，错误依旧。
1.安装相关依赖环境：
+1 | $ sudo apt-get install build-essential fakeroot dpkg-dev libcurl4-openssl-dev |
2.获取git源码：
+1 | $ sudo apt-get source git |
若出现如下错误：
+1 | E: You must put some 'source' URIs in your sources.list |
则需要将设置->Software & Updates->Ubuntu Software->Source code勾选：
若出现如下错误：
+1 | couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) [duplicate] |
则需要更改权限：
+1 | sudo chown _apt /var/lib/update-notifier/package-data-downloads/partial/ |
3.安装git的依赖
1 | $ sudo apt-get build-dep git |
4.进入git目录，重新编译：
1 | $ cd git-2.7.4/ |
5.回到上一级目录，安装编译好的安装包：
+1 | $ cd .. |
执行完成如上步骤后，重新clone，发现依旧报错，请看错误二。
1 | remote: Counting objects: 10994, done. |
重新确认postBuffer，配置确实生效了：
1 | $ cat ~/.gitconfig |
晕，实在搞不定了，采取极端方法，首先clone一层：
1 | $ git clone --depth=1 http://xxx.git |
浅层clone成功后，再完整拉取：
1 | $ git fetch --unshallow # 拉取完整当前分支 |
至此，终于成功地clone了一个完整的仓库。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2019/09/09/git-clone-extra-large-project/ +
发表日期：2019/09/09 12:09
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将介绍Homebrew的安装与使用。
Homebrew是OS X上类似于apt-get和yum的软件包管理器，软件源依托于Github之上，所以在国内的网络环境之下，常常会出现使用Homebrew安装软件时，如brew install sshfs，经常会长时间卡在Updating Homebrew...。
+++
OS X 10.9开始支持
首先安装依赖Xcode命令行工具：
1 | $ xcode-select --install |
然后安装Homebrew：
1 | $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" |
1 | $ ruby -e "$(curl -fsSL $https://raw.githubusercontent.com/Homebrew/install/master/uninstall)" |
当安装过程中，卡在Updating Homebrew...时，我们可以按住control + c，来取消本次更新；之后命令行会显示^C，表示取消成功，后面会继续安装工作。
++这个方法是临时，仅在本次安装生效。
+
Homebrew的软件源更新，是在每次安装时自动执行的，可以通过配置进行关闭。
zsh终端方式：
1 | $ echo 'export HOMEBREW_NO_AUTO_UPDATE=true' >> ~/.zshrc |
bash终端方式：
1 | $ echo 'export HOMEBREW_NO_AUTO_UPDATE=true' >> ~/.bash_profile |
++这个方法是永久的，每次安装都会生效，但弊端是无法获取最新的软件。
+
这里推荐中科大的镜像源，亲测可用。
+1 | $ cd "$(brew --repo)" |
还原官方源：
+1 | $ cd "$(brew --repo)" |
1 | $ cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core" |
还原官方源：
+1 | $ cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core" |
1 | $ cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-cask |
若提示找不到"$(brew --repo)"/Library/Taps/homebrew/homebrew-cask，则：
1 | $ cd "$(brew --repo)"/Library/Taps/homebrew/ |
还原官方源：
+1 | $ cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-cask |
+++
brew cask安装软件，会自动创建软链接到Application目录，这样在Launchpad中也能查看到安装的软件，方便启动软件
zsh终端方式：
1 | $ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.zshrc |
bash终端方式：
1 | $ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.bash_profile |
还原官方源：进入如上终端配置文件，并删除HOMEBREW_BOTTLE_DOMAIN改行配置，并source终端配置文件，使之生效。
Error: Another active Homebrew update process is already in progress.rm -rf /usr/local/var/homebrew/locks查看Homebrew版本：
+1 | $ brew -v |
Homebrew帮助信息：
+1 | $ brew [cask] -h |
更新Homebrew：
+1 | $ brew update |
更新Homebrew cask：
+1 | $ brew cask upgrade |
安装软件：
+1 | $ brew [cask] install <packageName> |
卸载软件：
+1 | $ brew [cask] uninstall <packageName> |
查询可用软件：
+1 | $ brew search <packageName> |
查看已安装软件：
+1 | $ brew [cask] list |
查看软件信息：
+1 | $ brew [cask] info <packageName> |
1 | $ echo $SHELL |
++ +输出
+/bin/zsh为zsh终端，输出/bin/bash为bash终端。
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2020/02/17/homebrew-in-mac/ +
发表日期：2020/02/17 20:02
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文记录了解决 --hash-style 兼容性问题的过程。
1 | dlopen failed: empty/missing DT_HASH in "libxxx.so" (built with --hash-style=gnu?) |
最近，稳定性监控平台，被这一行错误日志霸榜，刚看到时也一脸懵逼，下面我们来逐步分析。
+首先需要查阅一下相关文档，了解一下其中的”新朋友”。
DT_HASH
1 | ELF 中的一个 Sections，保存了一个用于查找符号的散列表，用于支持符号表的访问，能够提高符号搜索速度。 |
--hash-style=style(以下解释摘自 man ld)
1 | Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU ".gnu.hash" section or "both" for both the classic ELF ".hash" and new style GNU ".gnu.hash" hash tables. The default is "sysv". |
通过查阅 --hash-style=style 参数，发现 style 支持三种配置：sysv、gnu和both，废话不多说，先试一把。
gcc -Wl,--hash-style=sysv
1 | $ readelf -S libxxx.so | grep "hash" |
gcc -Wl,--hash-style=gnu
1 | $ readelf -S libxxx.so | grep "hash" |
gcc -Wl,--hash-style=both
1 | $ readelf -S libxxx.so | grep "hash" |
+++
-Wl用于编译器向链接器传递参数。
如上，发现使用不同的配置，Sections Name 不同。
+++
.gnu.hash段，提供了与hash段相同的功能；但是与hash相比，增加了某些限制（附加规则），导致了不兼容，带来了50%的动态链接性能提升，具体参见 https://blogs.oracle.com/solaris/gnu-hash-elf-sections-v2。
结合实验结果，我先翻译一下问题中的那一行错误日志：
+1 | 动态库加载失败，libxxx.so 中 DT_HASH 为空或者丢失，是不是用了 --hash-style=gnu 编译? |
结合上表，若 --hash-style=gnu，那么 Section Name 就是 .gnu.hash 了，当然找不到.hash 了。
再查阅一下 Makefile 配置，发现并没有相关配置，怀疑是编译器的默认配置：
1 | $ gcc -dumpspecs | grep "hash" |
+++
-dumpspecs参数可以打印编译器的内置规范。
果不其然，默认的 --hash-style 配置为了 gnu。
输出的动态库的 --hash-style 为 gnu，而目标系统并不能正确读取 --hash-style 为 gnu 的动态库，导致了如上的错误。
配置 --hash-style 为 both：
1 | LDFLAGS += -Wl,--hash-style=both |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2020/05/14/ld-hash-style/ +
发表日期：2020/05/14 15:05
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 根据我求职与招聘的经验，结合网上相关资料，这里整理了一些写好技术简历的建议。
+ + +++这里提供了一份简历模版，可供参考。
+
写简历必须要保证内容的真实性，这是候选人个人诚信的体现，无论在简历中如何自夸，最终会在面试过程中也会露怯；同时现在大部分企业在招聘时，都会进行背调，所以请务必保证简历内容包括面试过程的真实性，实事求是，“知之为知之，不知为不知”。
+对于技术人员来说，项目经历是简历的主体，也是简历中最需要突出的部分，项目中涉及的技能和成果等，是对求职者能力最具说服力的证明。
+据说，谷歌要求求职者描述项目经历时，必须提供下面三个信息：
+这里我认为还可以增加一个信息，即在项目中的角色：
+比如，”在 xx 产品中，主导开发了 xx 功能，使用了 xx 技术，解决了 xx 问题，带来了 xx 增长或收入”。
++特别需要注意的是，取得的结果一定要量化，如功能被多少人使用、性能提升多少倍、节约了多少成本、带来了多少收益等等
+
除此之外，还请注意下面几点：
+3~5 年内的项目，除非特别有价值，否则不要描述过于旧的项目；2~3 个核心的项目详细描述，其余可一笔带过；我遇到过很多刚毕业或毕业不久的求职者，简历中的专业技能十分齐全，但是面试过程中却发现大多的技能，仅仅是接触过或者在学校学过，这会给人感觉“你什么都会一点，但是什么都不精通”，这样做的伤害大于帮助。
+所以，请筛选你的专业技能，建议可以按照熟练程度进行分类：
+最后，与专业无关的技能切勿出现在简历中，那这些内容对企业没用，缺乏针对性，只会浪费简历空间，如在校上过的课程、得过的奖学金、当过学生会干部，会计证、驾驶证、英语四六级考试等。
+企业招聘的目的，是希望找到能够帮助它干活或解决问题的人，仅仅通过一份简历，它也没有把握什么样的人匹配这个岗位，所以它只能假设如果你掌握了这个岗位所需要的某几种核心专业技能，你就是初步合格的候选人。
+所以简历应该针对每个应聘的岗位，突出该岗位所需要的项目经历和专业技能，来证明你可以胜任这份工作。
+简历是求职者用来向企业传递信息的，一般来说企业招聘人员在筛选简历时，阅读简历的时间不会超过半分钟，如果看不到想要的点，就会直接 pass；所以一定要突出重点内容，不要写得密密麻麻，堆砌各种无关的信息，这样只会增加简历的阅读难度，让招聘人员抓不到重点，对于技术人员来说，重点就是你的项目经历以及专业技能。
简历中应该避免出现错别字、语法错误等低级错误，这很有可能会给企业留下不严谨、做事马虎的印象；同时技术名词大小写也应该遵循业内规范，保持专业性。
+如果对自己不放心，可以在发送简历之前，请朋友检查一遍简历。
+一般简历中，都会要求候选人进行自我评价，请注意不要描述自己的工作态度，如积极进取、工作努力等，这是默认应该做到的，不是加分项。
自我评价可以针对如下四点进行：
优化企业招聘人员在阅读简历时的体验，使你的简历比别人读起来更舒服，自然简历通过的机会也会更高，可以关注以下细节：
+markdown 编写，转换成 pdf 格式发出，可以避免样式丢失或格式不兼容；重中之重，还是需要提高自己的能力，正所谓 “酒香不怕巷子深“。
+原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2020/07/03/gudie-of-technical-resume/ +
发表日期：2020/07/03 11:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文是对Git速查手册（第二版）的更新，补充了一些近期使用或者收集的一些命令。
+ + +Git下载地址：https://git-scm.com/downloads，安装请参考页面说明。
++建议使用版本
+v1.8及以上。
Git配置分为三个级别：
--system：系统级，位于 /etc/gitconfig；--global：用户级，位于 ~/.gitconfig；--local：仓库级，位于 [repo]/.git/config，为默认级别且优先级最高；删除global用户信息，防止不同Git服务之间冲突：
1 | $ git config --global --unset user.name |
配置用户名：
+1 | $ git config --local user.name "username" |
一般Git服务默认都支持SSH和HTTPS，SSH支持的原生Git协议速度最快，HTTPS除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令。
检查本机SSH公钥，若存在，则将id_rsa.pub添加到Git服务的SSH keys：
1 | $ ls ~/.ssh |
若不存在，则生成：
+Git服务1 | $ ssh-keygen -t rsa -C "your_email@youremail.com" |
Git服务1 | $ ssh-keygen -t rsa -C "your_email@youremail.com" -f "git1_id_rsa" |
配置完成后，将对应的id_rsa.pub添加到Git服务的SSH keys，再次检查ssh连接情况；若不生效，则重启后再尝试：
1 | $ ssh -T git@github.com |
++若出现上述信息，则表示设置成功。
+
克隆：
+1 | $ git clone git@git.server:test.git |
关闭ssl校验：
1 | $ git config --global http.sslverify false |
克隆：
+1 | $ git clone https://git.server/test.git |
查看当前协议：
+1 | $ git remote -v |
从https切换至ssh：
1 | git remote set-url origin git@domain:username/ProjectName.git |
从ssh切换至https：
1 | git remote set-url origin https://domain/username/ProjectName.git |
1 | $ git config --global credential.helper 'cache --timeout=3600' |
1 | $ git config --global credential.helper store |
执行后，下次操作输入的用户名和密码会被保存，后续不必手动输入用户名和密码。若同时使用不同的Git服务，则不推荐使用。
若同时使用不同的Git服务，可以根据目录配置用户信息（需要使用v2.13.0及以上版本）：
首先修改用户目录下的 .gitconfig，通过 includeIf 配置不同目录的配置文件：
1 | - [user] |
根据配置的 path，分别创建 .gitconfig-github 文件和 .gitconfig-gitlab 文件：
1 | $ vi .gitconfig-github |
includeIf 配置有如下规则：
家目录下的 .gitconfig ，includeIf 后面的 path 最后需要 / 结尾；
家目录下的 .gitconfig ，原有的 user 部分需要删除；
家目录下的 .gitconfig ，includeIf中配置的各个目录，不能是包含关系；
Linux or MacOS：
1 | $ git config --global core.editor vim |
Windows：
1 | > git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" |
查看支持的工具集合（推荐使用meld）：
1 | $ git difftool --tool-help |
Linux or MacOS：
1 | $ git config --global diff.tool meld |
Windows：
1 | > git config --global diff.tool meld |
1 | $ git config --global color.ui.true |
示例，将checkout设置为别名co：
1 | $ git config --global alias checkout co |
1 | $ git config --local --list |
工作区就是你的本地仓库目录，不过其中的.git目录不属于工作区，而是版本库，里面存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
查看状态：
+1 | $ git status |
添加修改到暂存区：
+1 | $ git add <filename> |
提交修改到版本库：
+1 | $ git commit -m "commit message" |
+++
commit message的填写可以参考写好 Git Commit 信息的 7 个建议。
现在来解释一下前面的添加和提交操作：
+git add：把文件修改添加到暂存区；git commit：把暂存区的所有内容提交到当前分支，即版本库；查看当前仓库所有文件的版本历史记录：
+1 | $ git log |
查看每个文件的版本历史记录：
+1 | $ git log <filename> |
查看包含指定关键字的版本历史记录：
+1 | $ git log --grep="keywords" |
查看指定时间段的版本历史记录，如下示例时间段为2020.9.23全天：
1 | $ git log --after="2020-9-23 00:00:00" --before="2020-9-23 23:59:59" |
当你需要切换分支时，若当前工作区还有些修改没有完成、又不适合提交的，操作切换分支是会提示出错的，这时就需要将这些修改暂存起来：
+1 | $ git stash save "message" |
查看:
+1 | $ git stash list |
恢复:
+1 | $ git stash pop [--index] [stash@{num}] |
+++
--index表示不仅恢复工作区,还会恢复暂存区；num是你要恢复的操作的序列号,默认恢复最新进度。
删除进度:
+1 | $ git stash drop [stash@{num}] # 删除指定进度 |
查看当前仓库状态：
+1 | $ git status |
查看文件更改：
+1 | $ git difftool <filename> |
查看提交历史：
+1 | $ git log |
撤销工作区Tracked files的修改：
1 | $ git checkout -- <filename> |
撤销工作区Untracked files的修改：
Untracked的文件；Untracked的目录；gitignore的Untracked文件和目录一并删掉，慎用！；1 | git clean -nfd |
只回退暂存区(git add)，不删除工作空间代码：
1 | $ git reset HEAD <filename> # 无filename则默认回退全部 |
回退版本区(git commit)和暂存区(git add)，不删除工作空间代码：
1 | $ git reset --mixed HEAD^ # --mixed为默认参数 |
回退版本区(git commit)，但是不回退暂存区(git add)，不删除工作空间代码：
1 | $ git reset --soft HEAD^ |
回退版本区(git commit)和暂存区(git add)，并删除工作空间代码(不包括Untracked files)，执行后直接恢复到指定<commit-id>状态：
1 | $ git reset --hard <commit-id> |
+++
HEAD表示当前版本，HEAD^表示上个版本，HEAD^^表示上上个版本，上100个版本可以表示为HEAD~100以此类推。
回退版本后，若需要返回原来的版本，会发现找不到未来的commit id，则需要查看操作命令历史进行查找：
1 | $ git reflog |
从版本库删除文件：
+1 | $ git rm <filename> |
若你的代码已经push到线上，则推荐使用下面这个命令回滚：
1 | $ git revert <commit-id> |
+++
revert是用一次新的commit来回滚之前的commit，更安全;reset则是直接删除指定的commit，若直接push会导致冲突。
查看帮助：
+1 | $ git --help |
1 | $ git push -u origin <feature-branch-name> |
+++
-u选项可以将本地分支与远程分支关联,下次git pull操作时可以不带参数.具体参见这里。
1 | $ cd repo |
+++
origin就是一个名字，是git为你默认创建的指向这个远程代码库的标签。
1 | $ git clone git@github.com:USERNAME/repo.git |
1 | $ git remote -v |
1 | $ git remote add upstream git@github.com:USERNAME/repo.git |
1 | $ git remote -v |
Git包含submodule和subtree两种引用方式，官方推荐使用subtree替代submodule：
1 | $ git submodule add git@github.com:USERNAME/repo.git <submodule-path> |
执行成功后，暂存区会有两个修改：.gitmodules和命令中<submodule-path>指定的路径。
提交更新：
+1 | $ git commit |
克隆使用了子模块的项目后，默认其子模块目录为空，需要在项目根目录执行如下命令单独下载：
+1 | $ git submodule update --init --recursive |
子模块仓库更新后，使用子模块的项目必须手动更新才能同步最新的提交：
+1 | $ cd <submodule-path> |
完成后返回项目根目录，可以看到子模块有待提交的更新，执行提交即可：
+1 | $ git add . |
删除子模块目录及源码：
+1 | $ rm -rf <submodule-path> |
删除项目根目录下.gitmodules文件中待删除的子模块相关条目：
1 | $ vi .gitmodules |
删除版本库下的子模块目录，每个子模块对应一个目录，只删除对应的子模块目录即可：
+1 | rm -rf .git/module/<submodule-path> |
删除子模块缓存：
+1 | git rm --cached <submodule-path> |
提交更新：
+1 | $ git add . |
1 | # 第一次初始化 |
1 | $ git pull # 拉取更新 |
1 | $ git branch -d <branch-name> |
查看仓库占用空间：
+1 | $ git count-objects -v |
寻找大文件ID：
1 | $ git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 |
++输出的第一列是文件
+ID，第二列表示文件（blob）或目录（tree），第三列是文件大小，此处筛选了最大的10条。
根据文件ID映射文件名：
1 | $ git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')" |
根据文件名，从所有提交中删除文件：
+1 | $ git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch [FileName]' --prune-empty --tag-name-filter cat -- --all |
删除缓存下来的ref和git操作记录：
1 | $ git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin |
清理.git目录并推送到远程：
1 | $ git gc --prune=now |
++在执行
+push操作时，git会自动执行一次gc操作，不过只有loose object达到一定数量后才会真正调用，建议手动执行。
重新查看仓库占用空间，发现较清理前变小很多：
+1 | $ git count-objects -v |
由于Git在存储二进制文件时效率不高，所以需要借助第三方组件。
查看所有分支：
+1 | $ git branch -a |
++有
+*标记的是当前分支。
查看某个<commit id>属于哪个分支:
1 | $ git branch -a --contains <commit id> |
在本地创建分支：
+1 | $ git branch <newbranch> # 创建 |
在本地创建分支并切换：
+1 | $ git checkout -b <newbranch> # 创建并切换 |
从标签创建分支：
+1 | $ git branch <newbranch> <tagname> |
获取远程分支到本地并创建本地分支：
+1 | $ git checkout -b <local-branch> <remote-branch> |
推送新建本地分支到远程：
+1 | $ git push -u origin <remote-branch-name> |
创建一个分支，该分支会包含父分支的所有文件，但不会指向任何历史提交：
+1 | $ git checkout --orphan <newbranch> |
删除所有文件：
+1 | $ git rm -rf . |
提交分支：
+1 | $ echo '# new branch' >> README.md |
删除本地分支：
+1 | $ git branch -d <branch> |
++若当前分支因为有修改未提交或其它情况不能删除，请使用
+-D选项强制删除。
清理无用的本地分支：
+1 | $ git remote prune origin |
++通常在
+remote上的分支被删除后，更新本地分支列表时使用。
删除远程分支(三种方法)：
+1 | $ git push origin --delete <remote-branch-name> |
获取远程分支到本地已有分支：
+1 | $ git branch --set-upstream <local-branch> origin/branch |
同步当前分支的所有更新，使用git pull并不保险：
1 | # 下载最新的代码到远程跟踪分支, 即origin/<branch-name> |
同步其它分支的所有更新，本例拉取master分支更新：
1 | $ git fetch origin master |
同步其它分支的部分更新，即同步某几次提交：
+1 | # 同步提交A |
1 | $ git tag |
1 | $ git tag -a <tagname> -m "tag message" # 创建标签在当前最新提交的commit上 |
++若创建标签基于的
+commit被删除，标签不会被影响，依旧存在。
推送标签到远程服务器：
+1 | $ git push origin <tagname> # 推送一个本地标签 |
1 | $ git tag -d <tagname> # 删除一个本地标签 |
当你的仓库中有一些文件，类似密码或者数据库文件不需要提交但又必须放在仓库目录下，每次git status都会提示Untracked，看着让人很不爽，提供两种方法解决这个问题。
在代码仓库目录创建一个.gitignore文件，编写规则如下：
1 | tmp/ # 忽略tmp文件夹下所有内容 |
+ ++
在用户目录创建一个.gitignore_global文件，编写规则同.gitignore，并修改~/.gitconfig：
1 | [core] |
如果添加的忽略对象已经Tracked，纳入了版本管理中，则需要在代码仓库中先把本地缓存删除,改变成Untracked状态:
1 | $ git rm -r --cached . |
1 | $ git rebase -i [git-hash| head~n] |
其中git-hash是你要开始进行rebase的commit的hash，而head~n则是从HEAD向前推n个commit
1 | $ git commit --amend |
修改最近一次提交的用户信息：
+1 | $ git commit --amend --author="GIT_AUTHOR_NAME <GIT_AUTHOR_EMAIL>" |
全局修改用户信息：
+1 | $ git filter-branch --commit-filter ' |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2020/09/29/git-help-v3/ +
发表日期：2020/09/29 15:09
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文从一个实际遇到的问题出发，分析 RPATH 与 RUNPATH 的区别，以及产生的原因。
年前升级了操作系统后，同样的代码在新系统编译后无法执行，提示找不到依赖库，本文用来记录一下是如何解决这个问题的。
+main.c ：
1 |
|
libA.so：
1 | // a.c |
1 | // a.h |
ubuntu 16.04(gcc version 5.4.0)：
1 | $ gcc -fPIC -shared a.c -I. -L. -lB -o libA.so |
libB.so：
1 | // b.c |
1 | // b.h |
ubuntu 16.04(gcc version 5.4.0)：
1 | $ gcc -fPIC -shared -I. b.c -o libB.so |
++**函数调用依赖关系：
+main->a->b**。
分别在 ubuntu 16.04(gcc version 5.4.0) 和 ubuntu 20.04(gcc version 9.3.0) 编译可执行程序：
1 | $ gcc -I. -o main main.c -Wl,--rpath,. -L. -lA -lB |
在 ubuntu 16.04(gcc version 5.4.0) 运行成功：
1 | $ ./main |
在 ubuntu 20.04(gcc version 9.3.0) 运行失败：
1 | $ ./main |
++错误提示为找不到可执行程序
+./main依赖的共享库libB.so。
首先，由于 libA.so 和 libB.so 是在 ubuntu 16.04(gcc version 5.4.0) 上编译的，所以重新在ubuntu 20.04(gcc version 9.3.0) 上编译 libA.so 和 libB.so，并重复复现步骤，现象相同，说明不是 libA.so 和 libB.so 导致的问题；
使用 **LD_DEBUG**，打开链接器的调试功能，分析共享库的查找过程：ubuntu 16.04(gcc version 5.4.0)：
1 | $ LD_DEBUG=libs ./main [16:37:15] |
ubuntu 20.04(gcc version 9.3.0)：
1 | $ LD_DEBUG=libs ./main |
结果在 ubuntu 20.04(gcc version 9.3.0) 中， 可以正确查找到 libA.so ，但是无法正确查找到 libB.so 。libB.so 的查找路径是 system search path ，而非我们在编译时设定的查找时路径 ./ ，导致可执行程序无法加载 libB.so 。
++动态链接器对共享库的查找顺序：
++
+- +
LD_LIBRARY_PATH、-L和-rpath；- +
/etc/ld.so.cache；- 默认共享库目录：
+/usr/lib、/lib；
由上分析可以得出是共享库运行时加载路径非法导致的问题，在排除设置 LD_LIBRARY_PATH 等环境变量的情况下，可以将焦点锁定在使用的链接选项 -rpath 上，查看源文件依赖：ubuntu 16.04(gcc version 5.4.0)：
1 | $ readelf -d main |
ubuntu 20.04(gcc version 9.3.0)：
1 | $ readelf -d main |
发现在 ubuntu 20.04(gcc version 9.3.0) 上 RPATH 变成了 RUNPATH ，说明链接器选项 -rpath 的行为发生了改变。
++源文件依赖关系：
+main->libA.so->libB.so；
综上，问题的原因是 ubuntu 20.04(gcc version 9.3.0) 上，链接器选项 -rpath 的行为发生改变，默认配置为 RUNPATH 而不是 RPATH；由于 RUNPATH 不适用于间接依赖的库，所以导致在 ubuntu 20.04(gcc version 9.3.0) 上只能正确查找到 libA.so ，而无法正确查找到 libB.so 。
+++
gcc version >= 7.5.0时，-rpath默认行为即发生改变。
LD_LIBRARY_PATH 是一个环境变量，作用是临时改变链接器的加载路径，可以存储多个路径，用冒号分隔：
1 | $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./libs |
不推荐的原因：
+LD_LIBRARY_PATH，会影响其它应用程序的共享库加载过程；LD_LIBRARY_PATH，则每次启动都需要设置，步骤过于繁琐；可以使用 -Wl,--disable-new-dtags 选项来使链接器保持旧行为，即在 ubuntu 20.04(gcc version 9.3.0) 使用如下命令编译：
1 | $ gcc -I. -o main main.c -Wl,--disable-new-dtags,--rpath,. -L. -lA -lB |
重新运行并查看依赖：
+1 | $ ./main |
可执行程序 main 可以正确运行，RUNPATH 也变成了 RPATH，链接器行为与 ubuntu 16.04(gcc version 5.4.0) 保持一致了。
++同理，也有
+-Wl,--enable-new-dtags选项来使链接器保持新行为
如下为官方解释：
+1 | --enable-new-dtags |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2021/02/22/difference-between-RPATH-and-RUNPATH/ +
发表日期：2021/02/22 18:02
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ getrusage用于统计系统资源使用情况，即进程执行直到调用该函数时的资源使用情况，如果在不同的时间调用该函数，会得到不同的结果。
getrusage用于统计系统资源使用情况，即进程执行直到调用该函数时的资源使用情况，如果在不同的时间调用该函数，会得到不同的结果。
++目前在
+Linux和macOS支持该函数。
1 |
|
+++
sys/time.h：为了得到timeval结构体的声明，这个结构体实际上在bits/time.h中声明。
**who**：资源统计的对象，有如下取值：
RUSAGE_SELF：返回调用进程的资源使用统计信息，即该进程中所有线程使用的资源总和；RUSAGE_CHILDREN：返回调用进程所有已终止且被回收子进程的资源使用统计信息。如果进程有孙子进程或更远的后代进程，且这些后代进程和这些后代进程与调用进程之间的中间进程也已终止且被回收，那么这些后代进程的资源使用统计信息也会被统计；RUSAGE_THREAD（Linux 2.6.26起支持）：返回调用线程的资源使用统计信息；| 宏定义 | +取值 | +
|---|---|
| RUSAGE_SELF | +0 | +
| RUSAGE_CHILDREN | +-1 | +
| RUSAGE_THREAD | +1 | +
++宏定义在
+sys/resource.h->bits/resource.h。
**usage**：资源使用统计信息，用如下结构体的形式返回到该指针指向的内存空间：
1 | struct rusage { |
结构体struct rusage各个成员释义如下：
ru_utime：返回进程在用户模式下的执行时间，以timeval结构的形式返回（该结构体在bits/timeval中声明）；ru_stime：返回进程在内核模式下的执行时间，以timeval结构的形式返回（该结构体在bits/timeval中声明）；ru_maxrss（Linux 2.6.32起支持）：返回rss（实际使用物理内存，包含共享库占用的内存）的大小，单位为KB；当who被指定为RUSAGE_CHILDREN时，返回各子进程rss的大小中最大的一个，而不是进程树中最大的rss；ru_ixrss：目前不支持；ru_idrss：目前不支持；ru_isrss：目前不支持；ru_minflt：缺页中断的次数，且处理这些中断不需要进行I/O，不需要进行I/O操作的原因是系统使用reclaiming的方式在物理内存中得到了之前被淘汰但是未被修改的页框。（第一次访问bss段时也会产生这种类型的缺页中断）；ru_majflt：缺页中断的次数，且处理这些中断需要进行I/O；ru_nswap：目前不支持；ru_inblock（Linux 2.6.22起支持）：文件系统需要进行输入操作的次数；ru_oublock（Linux 2.6.22起支持）：文件系统需要进行输出操作的次数；ru_msgsnd：目前不支持；ru_msgrcv：目前不支持；ru_nsignals：目前不支持；ru_nvcsw（Linux 2.6起支持）：因进程自愿放弃处理器时间片而导致的上下文切换的次数（通常是为了等待请求的资源）；ru_nivcsw（Linux 2.6起支持）：因进程时间片使用完毕或被高优先级进程抢断导致的上下文切换的次数；++其中有些结构体成员目前并不被
+Linxu支持，但是为了兼容其它系统以及未来扩展，仍被保留了下来，这些结构体成员在函数执行后会被内核默认设置为0。
成功：0；
失败：-1，并设置errno的值，包含如下两种错误：
EFAULT：usage指针指向不可访问地址；EINVAL：who被指定为无效值；getrusage函数是线程安全的。
1 |
|
++ +完整代码：https://github.com/AnSwErYWJ/DogFood/blob/master/C/getrusage.c。
+
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2021/06/23/getrusage/ +
发表日期：2021/06/23 15:06
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ GCC在不优化时不会内联任何函数，除非指定函数的“always_inline”属性。
先附上结论：**GCC在不优化时不会内联任何函数，除非指定函数的“always_inline”属性。**
测试代码：
+1 |
|
使用-O3优化选项，一切正常：
1 | $ gcc -O3 -o test_O3.o -c test.c |
使用-O0优化选项，链接时报错，提示找不到内联函数say：
1 | $ gcc -O0 -o test_O0.o -c test.c |
分别查看文件test_O0.o和test_O3.o：
1 | $ readelf -s test_O0.o |
1 | $ readelf -s test_O3.o |
可以发现文件test_O0.o中，inline修饰的函数say为未定义状态，说明inline函数并没有展开。
指定say函数为“always_inline”属性：
1 |
|
重新使用-O0优化选项编译运行，一切ok：
1 | $ gcc -O0 -o test.o -c test.c |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2021/07/28/tips-of-inline/ +
发表日期：2021/07/28 14:07
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文将详细分析不同格式的wav文件。
wav即wave（下文统称为wav）, 该文件格式是由微软开发的用于音频数字存储的标准，可应用于Windows、Linux和MacOS等多种操作系统，文件扩展名为.wav，是waveform的简写。
在Windows下，大部分多媒体文件都遵循RIFF（Resource Interchange File Format，资源互换文件格式）格式来存储数据。
RIFF文件的基本存储单位称为块（chunk），一个遵循RIFF格式的文件由若干个chunk组成，每个chunk又由块标识、块长度和块数据三部分构成，其基本结构见表1：
| Field | +Size(bytes) | +Type | +
|---|---|---|
| 块标识 | +4 | +S8 * | +
| 块长度 | +4 | +U32 | +
| 块数据 | ++ | S8 * | +
**表1** `chunk`基本结构
+ +4个ASCII字符组成，如不满4个字符则在右边以空格充填，如：RIFF、LIST、fmt 和data等；chunk的实际长度为该值加8;NULL；特别需要注意的是，RIFF格式规定只有块标识为RIFF或LIST的块可以含有子块（subChunk），而其它块只可以包含数据。块标识为RIFF或LIST的块的结构与表1大致相同，只不过其块数据域分为两部分：
type：由4个ASCII字符组成，代表RIFF文件的类型，如WAVE和AVI ，或者代表LIST块的类型，如avi文件中的列表hdrl和movi；data：实际的块内容，包含若干subChunk；wav文件是非常简单的一种RIFF文件，其本身就是由一个块标识为RIFF的chunk和多个subChunk组成的一个chunk，其组成如下：
RIFF chunk：主块，必选，块标识为RIFF，说明这是一个RIFF文件，RIFF文件的第一个块标识必须是RIFF；Format chunk：子块，必选，块标识为fmt ，用于存储文件的一些参数信息，比如采样率、通道数和编码格式等；Fact chunk：子块，可选，块标识为fact，基于压缩编码的wav文件必须含有fact块；List chunk：子块，可选，块标识为LIST，用于记录文件版权和创建时间信息；Data chunk：子块，必选，块标识为data，用于存储音频数据；目前业界标准的wav文件仅由RIFF chunk、Format chunk和Data chunk组成：
wav文件从数据类型上看，主要由文件头和数据体两部分组成：
RIFF chunk、Format chunk、List chunk和Fact chunk等组成，用于存储一些文件信息；Data chunk组成，用于存储音频数据；标准的wav文件头仅由RIFF chunk和Format chunk组成，长度为44个字节，格式见表2：
| file offset(bytes) | +Field name | +Field size(bytes) | +type | +endian | +description | +
|---|---|---|---|---|---|
| 0 | +Chunk ID | +4 | +S8 * | +big | +“RIFF”，表明为RIFF文件 | +
| 4 | +Chunk Size | +4 | +U32 | +little | +除了RIFF及自己之外，整个文件的长度，即文件总字节数减去8字节 | +
| 8 | +Format | +4 | +S8 * | +big | +“WAVE”，表明为wav格式 | +
| 12 | +Subchunk1 ID | +4 | +S8 * | +big | +“fmt “ | +
| 16 | +Subchunk1 Size | +4 | +U32 | +little | +表示fmt数据块即subchunk1除了Subchunk1 ID和Subchunk1 Size之后剩下的长度，一般为16, 大于16表示存在扩展区域，可选值为16、18、20、40等 | +
| 20 | +AudioFormat | +2 | +U16 | +little | +编码格式，即压缩格式，0x01表示pcm格式，无压缩，参见表3 | +
| 22 | +NumChannels | +2 | +U16 | +little | +音频通道数，单声道为1，立体声或双声道为2 | +
| 24 | +SampleRate | +4 | +U32 | +little | +采样频率，每个通道单位时间采样次数，可选值为16000kHz和44100kHz等 | +
| 28 | +ByteRate | +4 | +U32 | +little | +数据传输速率，可用此估算缓冲区长度，ByteRate = SampleRate * NumChannels * (BitsPerSample / 8) | +
| 32 | +BlockAlign | +2 | +U16 | +little | +采样一次的字节数，即一帧的字节数，表示块对齐的内容（数据块的调整数），播放软件一次处理多少个该长度的字节数据，以便将其用于缓冲区的调整，BlockAlign = NumChannels * (BitsPerSample / 8) | +
| 34 | +BitsPerSample | +2 | +U16 | +little | +采样位宽，即每个采样点的bit数，可选值8、16或32等 | +
| 36 | +Subchunk2 ID | +4 | +S8 * | +big | +“data” | +
| 40 | +Subchunk2 Size | +4 | +U32 | +little | +音频数据的总长度，即文件总字节数减去wav文件头的长度 | +
| 44 | +Data | ++ | + | little | +音频数据 | +
**表2** 标准的`wav`文件头格式
+ +通过wav文件头信息，我们可以计算出音频时长:
1 | 音频时长(s) = Subchunk2 Size / ByteRate |
wav文件几乎支持所有ACM规范的编码格式，其信息存储在wav文件头偏移20、21两个字节中，常见的压缩编码格式见表3：
| 格式代码 | +格式名称 | +Format chunk 长度 | +是否有Fact chunk | +
|---|---|---|---|
| 0 (0x0000) | +unknown | +unknown | +unknown | +
| 1 (0x0001) | +PCM/uncompressed | +16 | +无 | +
| 2 (0x0002) | +Microsoft ADPCM | +18 | +有 | +
| 3(0x0003) | +IEEE float | +18 | +有 | +
| 6 (0x0006) | +ITU G.711 a-law | +18 | +有 | +
| 7 (0x0007) | +ITU G.711 µ-law | +18 | +有 | +
| 17 (0x0011) | +IMA ADPCM | +unknown | +unknown | +
| 20 (0x0016) | +ITU G.723 ADPCM (Yamaha) | +unknown | +unknown | +
| 49 (0x0031) | +GSM 6.10 | +20 | +有 | +
| 64 (0x0040) | +ITU G.721 ADPCM | +unknown | +有 | +
| 80 (0x0050) | +MPEG | +unknown | +unknown | +
| 65,534 (0xFFFE) | +扩展格式标识 | +40 | +unknown | +
| 65,536 (0xFFFF) | +Experimental | +unknown | +unknown | +
**表3** 常见的压缩编码格式
+ +当然，也不是所有的wav文件头都是44个字节的，比如通过FFmpge编码而来的wav文件头通常大于44个字节，目前比较常见的wav文件头长度有44字节、46字节、58字节和98字节。
当wav文件采用非PCM编码即压缩格式时，会扩展Format chunk，在其之后扩充了一个数据结构，见表4：
| file offset(bytes) | +Field name | +Field size(bytes) | +type | +description | +
|---|---|---|---|---|
| 24 | +extand size | +2 | +U16 | +除其自身外的扩展区域长度 | +
| 26 | +extand area | ++ | + | 包含扩展的格式信息，其长度取决于压缩编码类型。当某种编码格式（如ITU G.711 a-law）使扩展区的长度为0时，该字段还必须保留，只是长度字段的数值为0。 | +
**表4** 标准Format chunk扩展格式
+ +++由此可以得出，如果
+Subchunk1 Size等于0x10(16)，表示不包含Format chunk扩展，wav文件头长度为44字节；如果大于0x10(16)，则包含Format chunk扩展，扩展长度的最小值为18(16+2)，此时wav文件头大于44字节。
当编码格式代码为0xFFFE时，Format chunk扩展长度为24字节，格式见表5。
| file offset(bytes) | +Field name | +Field size(bytes) | +type | +description | +
|---|---|---|---|---|
| 24 | +扩展区长度 | +2 | +U16 | +值为22 | +
| 26 | +有效采样位数 | +2 | +U16 | +最大值为 每个采样字节数 * 8 | +
| 28 | +扬声器位置 | +4 | +U32 | +声道号与扬声器位置映射的二进制掩码 | +
| 32 | +编码格式 | +2 | +U16 | +真正的编码格式代码 | +
| 34 | ++ | 14 | ++ | 值为{\x00, \x00, \x00, \x00, \x10, \x00, \x80, \x00, \x00, \xAA, \x00, \x38, \x9B, \x71} | +
**表5** 编码为0xFFFE的Format chunk扩展格式
+ +采用压缩编码（修订版Rev.3以后出现的编码格式）的wav文件必定有含有Fact chunk，其结构符合标准chunk结构，参见表1。
Fact chunk的块标识符为”fact“，块长度至少为4个字节，目前其只有一个块数据内容，即每个声道采样总数，或采样帧总数。该值等于Subchunk2 Size / BlockAlign。
值得注意的是，在实测中发现，将压缩编码格式文件转换成PCM编码格式后，原Fact chunk仍然存在。
wav文件格式是一种极其简单的文件格式，如果对其结构足够熟悉，完全可以通过代码正确读写，从而免去引入一些复杂的中间库，降低复杂度，提高工作效率。
这里提供了一个wav文件动态解析库，欢迎使用。
+原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2022/01/06/wav/ +
发表日期：2022/01/06 10:01
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+ 本文对作者2018年的博文Linux下core文件使用做了一系列更新，特别是针对Ubuntu 20.04下core文件生成异常做了分析与解决。
在Linux下遇到程序异常退出或者中止，操作系统通常会把程序当前的工作状况存储在一个名为core的文件中，其中包含了程序运行时的内存、寄存器和堆栈指针等信息，格式为ELF，这个过程叫做coredump，又称作核心转储。
通过工具分析这个文件，我们可以定位到程序异常退出或者终止时相应的堆栈调用等信息。
+1 | $ ulimit -a |
0 表示core文件大小限制为0，不允许写入，所以无法生成core文件，需要修改为正数大小或unlimited才可使coredump生效。
取消core文件大小限制：
1 | ulimit -c unlimited |
也可以对core文件的大小进行有效限制，单位为blocks，一般1 block=512 bytes，设置太小可能导致不会生成文件：
1 | $ ulimit -c 1024 |
++上面对
+core文件的操作仅对当前生效，若需要永久生效，则要将相应操作写入/etc/profile。
core文件默认存储在程序的工作目录，可以通过命令cat /proc/sys/kernel/core_pattern 查看。
在文件/etc/sysctl.conf末尾加入如下信息，可以指定core文件的存储路径：
1 | kernel.core_pattern=/dumpdir/core_%e_%p_%t |
控制core文件的文件名中是否添加pid作为扩展：
1 | echo "1" > /proc/sys/kernel/core_uses_pid |
+++
/proc/sys/kernel/core_uses_pid这个文件的值若为１，则无论是否配置%p，最后生成的core文件都会添加pid。
通常情况下，重启即可生效。
+附core文件命名使用的参数列表：
1 | %p - insert pid into filename # 添加 pid |
Ubuntu 20.04中，执行完上述操作，会发现还是无法在指定目录生成core文件。
查看core文件存储路径：
1 | $ cat /proc/sys/kernel/core_pattern |
发现core文件存储路径并非自己设置的，而是由管道交给了一个apport的程序，通过查询可知其是Ubuntu官方为了自动收集错误，生成程序崩溃报告的一个服务，即apport.service。
我们可以关闭apport.service这个服务：
1 | sudo service apport stop |
++使用
+sudo service apport start可以开启这个服务。
如果这个命令无效的话，可以修改/etc/default/apport文件，将enabled改成0。
如上，可以在指定路径生成core文件。
可以使用gdb对core文件进行调试：
1 | $ gdb a.out |
++编译可执行程序时需要带上
+-g选项。
如需要在PC上调试嵌入式设备产生的core文件，则需要选取相应平台的gdb工具，并在进入gdb后设置符号文件的位置：
1 | $ xxx-xxx-gdb a.out |
原文作者：AnSwErYWJ +
原文链接：https://answerywj.com/2022/12/20/generate-and-usage-of-core-in-linux/ +
发表日期：2022/12/20 17:12
+版权声明：本文采用Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License进行许可.
+
+ Linux C/C++, Shell/Python/Matlab/Lua Cortex-A(Neon/ACL), Qualcomm aDSP/cDSP(QHL/HVX/HTA), Tensilica HIFI3/4/5；Android Audio, 包括Audio HAL/ALSA/AudioFlinger等有工作机会欢迎联系~
+ +
+ 心跳机制用于保持客户端和服务端的连接.
+本文将介绍UNIX网络编程中connect函数及其包裹函数。
DEBUG宏用于Linux下C编程时调试使用.
+字节流套接字（TCP套接字）上的read和write函数所表现的行为不同于通常的文件I/O。字节流套接字调用read或write输入或输出的字节数可能比请求的数量少，然而这并不是出错的状态。这是因为内核中用于套接字的缓冲区可能达到了极限。通常这种情况出现在一次读多于4096个字节或write在非阻塞情况下返回不足字节数。为了不多次调用read或防止write返回不足字节数，我们用下面的两个函数来替代read和write。
+本文将介绍C语言生成随机数的方法,主要使用 rand() 函数和 srand() 函数.
+Shell脚本是用户与Linux操作系统交互的一种方式,在脚本编程过程中自然少不了进行调试工作,本文将介绍三种常用的调试方法.(默认使用bash shell)
+Linux下adb工具下载，下载解压到*/usr/bin*目录。
+在Linux开发环境下，想要录制一段屏幕视屏不是特别方便。这里分享给大家一种方便而且快捷的方法。
+**:(){ :|: & };:**是一个bash函数，以Fork Bomb闻名，是一个拒绝服务攻击 的Linux 系统。如果你好奇地去执行了这个命令，那么赶快重启系统吧~！
+