最近在使用某几个知名厂商的对象存储C SDK时，发现由于这些SDK的内部实现其实基本是一样的，进而导致了各个SDK的so中都或多或少有些被大家共同喜爱的全局函数（符号）名称，最后引发了在部分环境中出现了调用A厂商SDK的上传函数时崩溃在了B厂商SDK的同名全局函数中的问题，最开始感觉很是莫名其妙，后来查了资料发现，首先gcc编译时默认会将全局变量、函数等符号导出在都动态库中，而同时全局函数的加载又是抢占式的，这点通过如下简单试验便可验证：
Continue reading…C, C++, Obj-C
FFmpeg 4.3.1 hls http(s)配新版Nginx WebDAV 无法删除切片bug
在使用FFmpeg进行hls推流输出时，发现配合新版Nginx (1.21) + WebDav组件的http服务器时，即使指定了m3u8切片数量以及删除无用切片的参数：
hls_list_size 5 -hls_flags delete_segments -hls
也没有在服务端正确删除无用切片，查看Nginx日志，发现每次FFmpeg发起的DELETE文件请求，都会跟随一个这样的报错：
DELETE with body is unsupported!
导致虽然FFmpeg删除文件的http请求到了Nginx，但实际并没有删除掉磁盘上的ts切片文件，时间一长，磁盘空间耗尽，然后就尴尬了…
Continue reading…CentOS 8运行其它环境编译的curl报77错误解决方法
此问题来源于经过Github Actions编译出来的curl执行程序，由于actions默认的构建环境都是Ubuntu的，编译构建出来的新版本curl放到CentOS 8上运行时，会提示类似如下内容的错误（仅限需要用到ssl证书的协议，如https）：
curl: (77) error setting certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
...
curl: (77) Error reading ca cert file /etc/ssl/certs/ca-certificates.crt - mbedTLS: (-0x3E00) PK - Read/write of file failed
按照网上搜到的说法，重新yum安装ca-certificates之类的都不起作用，查看/etc/ssl/certs目录，发现有如下内容：
Continue reading…C/C++格式化字符串的一个小坑
格式化字符串是个写C/C++代码是很常见的东西，例如下面这段用了printf的简单代码：
#include <string>
int main()
{
std::string test = "hello world!";
printf("%s", test.c_str());
return 0;
}
虽然看起来有点怪，混用了C++的string和C的printf输出，其实换成char *也是可以的，不过，这并不重要，重要的是我有时会偷懒把上面这段代码写成这样：
#include <string>
int main()
{
std::string test = "hello world!";
printf(test.c_str());
return 0;
}
这样写，看起来似乎输出没有问题，两份代码的结果都是输出”hello world!”，并没有什么区别，那标题说的坑到底在哪呢？考虑这种情况，我们的test字符串里放的不再是简单的 hello world! 了，而是比如转义过的URL串，如“http://www.baidu.com/测试”会被转义成“http%3A%2F%2Fwww.baidu.com%2F%E6%B5%8B%E8%AF%95”，此时如果再用偷懒的写法，直接printf这个字符串，显而易见的就会出问题了！
Continue reading…
VS2019 16.9版引入的linux项目远程输出路径bug
这是一个Visual Studio 2019（博主发现时的版本是Community 16.9.4）的bug，之前在16.8版本的时候是没有问题的，并且影响的是VS原生的远程linux项目，Make CMake项目不受影响，发现这个问题时着实郁闷了一段时间，总结一句话就是这个选项：
红框内的两个dir，在16.9以前可以同时作用于本地windows项目路径，及同步到远端linux的项目路径，而到了16.9的时候无论怎么修改这两个路径都只有windows侧的路径会响应变化，而sync到linux的路径还会使用默认的这个路径（应该是bug或其它原因，比如，写死了？！），查了半天也没找到解决方法，对简单项目的话只好修改项目设置，都是用默认dir，或者想办法退回16.8版本，其中搜索过程中发现了有人提到这个问题：https://developercommunity.visualstudio.com/t/VS-For-Linux:-Output-files-on-remote-mac/1357691，其中提到已经修改等待发布，在此记录这个影响挺大的问题，后续有更新会同步过来…
UPDATE1: 16.10版本中已修改这个问题，加入了独立控制远端生成路径的选项。
关于typedef指针类型后的非主流const行为(misc-misplaced-const)
这是一个之前没怎么注意过的细节问题，首先，参加如下代码：
struct MyStruct
{
int type;
char name[40];
};
typedef MyStruct * PMyStruct;
int main(int argc, char * argv[])
{
MyStruct my1{0}, my2{0};
const MyStruct * pmy1 = &my1;
pmy1 = &my2;
const PMyStruct pmy2 = &my1;
pmy2 = &my2;
}
很简单的一段代码，但是全引出了一个不寻常的问题：此段代码编译时，第二个pmy2结构体指针会导致编译器(gcc)报错：“error: assignment of read-only variable ‘pmy2’”，此时如果配合有clang-tidy之类的代码扫描工具，会发现pmy2声明赋值位置提示：“Clang-Tidy: ‘pmy2’ declared with a const-qualified typedef; results in the type being ‘MyStruct *const’ instead of ‘const MyStruct *’”（clang-tidy的misc-misplaced-const）！
Continue reading…
解决UE4在中文环境下Compile错误提示乱码问题
UE4 4.26.0，VS 2019 Community，中文Win10 20H2组合在一起出现了今天要讲的问题，Compile出错时的log信息中中文乱码：
试过切换VS语言为英文，UE4语言为中文，均不起作用，想起之前的这个问题：Android Studio的Build Output中文输出乱码(菱形问号)问题的解决方法，以为是不是UE4也有类似的设置，查找半天无果，最后发现其实新版Win10（最早哪个版本加上的我也不清楚）里面的区域语言设置中有个UTF-8的选项，虽然到目前用的20H2时仍声称为beta状态，但确实可以解决这个问题：
Continue reading…关于clang的-Wweak-vtables警告
首先，这个weak-vtables的完整警告信息大概长这样：
warning: ‘XXX’ has no out-of-line virtual method definitions; its vtable
will be emitted in every translation unit [-Wweak-vtables]
而这个警告信息的来源一般是这样：
// XXX.h中
class BaseData
{
public:
virtual ~BaseData() = default;
int _base_data = 0;
};
class DerivedDataA final : public BaseData
{
public:
int _derived_data_a = 0;
};
class DerivedDataB final : public BaseData
{
public:
int _derived_data_b = 0;
};
VS Linux项目编译g++: fatal error: cannot specify -o with -c, -S or -E with multiple files问题
使用Visual Studio (2019)进行Linux项目开发时遇到项目编译时提示如标题所写的：
g++: fatal error: cannot specify -o with -c, -S or -E with multiple files
仔细检查了项目代码，并没有发现问题，也尝试了移除最近改动过的代码、增加过的源码文件，均不能正常编译…（同时，也确认过新建的项目可以正常编译，证明开发环境本身还是没问题的）
Continue reading…一种通过C++模板方式识别无用户数据C回调函数的方法
今天记录一个个人觉得有点意思的问题：在C++代码中调用C API时，对于C回调函数的处理问题，如何识别出调用API时的信息？
这个问题，大部分API都是通过调用时提供传递用户数据的方式实现的，如libcurl中的CURLOPT_WRITEDATA，CURLOPT_READDATA ，通过curl_easy_setopt方式将任意用户数据指针传递给CURL句柄，并在执行上传下载时的回调函数内透传给调用方，这样在例如多线程并发上传下载时就可以很方便的识别出是哪个上传下载任务的回调了。但是，如果API及回调函数内没有提供传递用户数据的接口和回调参数的话，是不是就一定无法完成识别调用上下文信息的功能呢？比如下列的C函数API：
// C-Style callback function without user context
typedef void (*c_api_callback_no_context)(int count);
// C-Style callback function with user context
typedef void (*c_api_callback_context)(int count, void * user_context);
// C API function that will trigger the callback function
void c_api_start_counting_no_context(c_api_callback_no_context callback, int max);
void c_api_start_counting_context(c_api_callback_context callback, int max, void * user_context);
c_api_start_counting_context及配套的c_api_callback_context回调为可以透传用户数据的版本，而c_api_start_counting_no_context及c_api_callback_no_context则只提供了逻辑用回调参数count，没有可用于识别context的用户数据指针，那么如何在不碰C源码的前提下(闭源C库或不想做侵入式修改)做到和带用户数据回调一样的效果呢？目前想到的一种方法是通过C++模板生成不同地址的回调函数配合上下文信息映射来实现：
Continue reading…