C语言sprintf格式化输出：格式串、缓冲区溢出与snprintf-北京尧图网络

1. 为什么sprintf值得单独拎出来讲刚接触C语言那会儿我对sprintf的态度是能用就行直到有一次在嵌入式项目里做数据上报格式化字符串写错了一个%d对应了double类型程序不崩但上报的数值全是乱码排查了整整两天。从那以后我就明白sprintf这类变参格式化函数属于用对了很顺手用错了很难查的典型代表。sprintf是C标准库stdio.h里的函数作用是把格式化的数据打印到一个字符数组里而不是输出到屏幕。你可以把它理解成printf的写内存版本printf往标准输出写sprintf往你指定的缓冲区写。这个区别看着小实际用途极大——拼装日志字符串、生成文件名、把数字转成字符串、构造协议报文、格式化时间戳几乎任何需要把多种类型的数据揉成一段文本的场景它都能顶上。它适合谁来学我的判断是只要你在写C迟早会用上。新手需要它来完成数字转字符串这种基础操作进阶开发者需要它做日志、做序列化嵌入式方向上的人更是绕不开它因为很多场景下你连printf都没有只能先sprintf到buf里再通过串口发出去。但这里有个前提必须说清楚sprintf本身不做任何边界检查缓冲区多大、写进去多少全靠你自己算。这也是它被诟病、被建议用snprintf替代的根本原因。所以这篇内容不会只讲怎么用更会讲怎么用不出事——参数怎么对、长度怎么算、什么时候必须换函数这些才是实战里真正值钱的部分。下面我按整体思路 → 核心细节 → 实操落地 → 问题排查的顺序展开中间会穿插一些我踩过的坑和实际项目里的做法你可以对照自己的代码看看有没有类似隐患。2. 整体设计思路与函数定位拆解2.1 从函数原型看它的本质一个带格式的字符串拷贝先看原型这是理解一切的基础int sprintf(char *str, const char *format, ...);三个部分拆开看。第一个参数str是目标缓冲区指针也就是往哪儿写第二个参数format是格式控制字符串决定怎么写后面的...是变参列表提供写什么。返回值是int表示成功写入的字符数不包含结尾的\0。这个返回值很多人忽略但它其实很有用——比如你想知道拼出来的字符串有多长直接接返回值就行不用再strlen一次。这里有个容易混淆的点返回值是int理论上可能出现负数编码错误时但绝大多数实现下只要是正常格式化就返回实际长度。我个人的习惯是在需要长度的场景下接住返回值但不会拿它做安全判断——因为真要溢出函数已经写完了返回值再准也晚了。长度必须在调用之前就算好这个思路后面会反复强调。理解sprintf的定位关键是想明白它和几个亲戚的关系。printf是输出到流sprintf是输出到内存snprintf是带长度限制的输出到内存fprintf是输出到指定流。它们共用同一套格式化规则所以你只要掌握了格式串的写法换函数只是换个目的地。这也是为什么很多人学完printf觉得sprintf不用学——规则确实一样但内存安全的责任完全转移到了调用者身上这才是差异所在。2.2 它到底解决了什么问题类型到文本的统一出口C语言是强类型语言int、float、char、指针各是各的想把它们拼成一段字符串理论上你可以对每种类型写一个转换函数但那太蠢了。sprintf的价值就在于提供了一个统一的、声明式的转换出口你用一个格式串描述我要什么样的文本剩下的转换工作交给库函数。具体来说它解决三类问题。第一类是数值转字符串比如把int的1234变成字符串1234这个需求在C里其实挺尴尬的因为没有内置的itoa它不是标准函数sprintf是最正统的做法。第二类是混合类型拼接比如temp%d, volt%0.2f这种一次调用把整数和浮点都塞进去。第三类是格式规范化比如补零、定宽、十六进制输出、左对齐右对齐这些用sprintf一行搞定手写循环要写一堆。我见过有同学为了避开sprintf自己写了个int_to_str函数结果负数处理错了、INT_MIN溢出了、前导零也没处理。这种轮子不是不能造但标准库已经验证过几十年的东西除非你有特殊约束比如某些安全规范禁用该函数否则没必要重造。真正需要花精力的是怎么安全地用而不是要不要用。2.3 方案选型的核心考量为什么它危险却仍在被大量使用sprintf最著名的问题就是不检查缓冲区边界。你给它一个char buf[10]格式串却要写进去20个字符它照样往里写后面的内存就被踩了。这个行为的后果是不确定的可能什么都没发生刚好那块内存没用可能改掉了旁边的变量可能直接段错误。这种不一定立刻出错的特性让它成为调试噩梦。那为什么还在用因为在很多场景下缓冲区大小是你自己可控的。比如你知道最大就是拼一个IP地址那char buf[16]就够了格式串也固定这种情况下用sprintf是安全的而且比snprintf少一个参数、少一次长度计算代码更干净。反过来如果格式化内容来自外部输入用户输入、网络数据长度不可控那就必须上snprintf。我的选型原则很朴素格式串和参数全在本地掌控内用sprintf有任何外部不可控因素用snprintf。举个具体例子拼日志行[%s] code%d其中%s是函数名——函数名是编译期确定的长度可控可以用sprintf但如果%s是用户传进来的字符串那必须snprintf并且要算上它的最大可能长度。这个判断标准比一律禁用或一律使用都更实际。还有一点值得说snprintf虽然安全但它有个行为差异——截断时返回的是本应写入的长度而不是实际写入的长度。这个细节后面会专门讲很多人在这儿栽过。2.4 格式串的本质一份微型规格说明书我一直觉得格式串是C语言里被低估的设计。它本质上是一份运行时的规格说明用极简的语法描述了数据怎么变成文本。一个格式说明符由几部分组成%开头然后是标志位-左对齐、0补零、显示正号、宽度、精度.n、长度修饰符l、ll、h、最后是转换类型d、u、f、s、x等。比如%08.3f拆开就是宽度8、补零、精度3位小数。理解了这个结构你就能自己组合出需要的格式而不用死记。我建议新手拿一张纸把常用的几个组合写下来贴在显示器边上用一周就记住了。格式串的危险之处在于它和参数列表是分离的。编译器只能检查格式串本身的语法无法完全校验后面的参数类型是否匹配现代编译器加了-Wformat能查一部分但变参的本质决定了它做不到全查。所以%d对应了一个double编译可能只给个警告运行时读到的就是一堆垃圾值。这类错误不会崩只会让数据悄悄错掉是最难查的一类。3. 核心细节解析与实操要点3.1 常用格式说明符速查与易错对照先把高频的列出来这张表我建议直接存下来说明符对应类型说明典型输出%dint有符号十进制-42%uunsigned int无符号十进制4294967295%ldlong长整型123456789%lldlong long更长的整型1234567890123%fdouble浮点默认6位小数3.140000%.2fdouble保留2位小数3.14%cint提升后单个字符A%schar *字符串hello%xunsigned int小写十六进制ff%Xunsigned int大写十六进制FF%pvoid *指针地址0x7ffd...%%无输出一个百分号%几个高频坑必须点出来。第一个是%f对应float——错。在变参传递中float会自动提升为double所以%f实际读的是double你传float反而会被提升能正常工作但如果传的是double却用了%d那就是灾难。第二个是%u和%d混用值小的时候看不出问题一旦超过INT_MAX%d会输出负数这个现象我在日志里见过好几次本质是同一个二进制被按不同符号解释。第三个是长度修饰符漏写。size_t是unsigned long64位平台用%u打印会截断一半long long用%ld同理。这类错误在32位上可能正常一换64位就暴露属于典型的移植时才炸的问题。我的做法是打印size_t统一用%zu打印long long统一用%lld养成肌肉记忆就不容易错。注意%c在变参中接收的是int因为char会整型提升所以传char变量是安全的但传指针就是错的——这个错编译器不一定报。3.2 宽度、精度与对齐格式串里的三个旋钮这三个概念是sprintf真正好用的地方也是新手最容易搞混的地方。我的理解方式是把格式串想象成一个格子宽度决定格子多宽精度决定格子里内容的精细程度或最大长度标志位决定内容在格子里怎么摆。宽度就是最小字符数。%5d输出1234会变成1234前面补空格输出123456则原样输出——宽度是下限不是上限。这一点很多人误以为是截断其实不会。想要补零就用%05d输出01234。补零和补空格的区别就是那个0标志位。精度对浮点是小数位数%.3f的3.14变成3.140。对字符串精度是最大长度%.5s处理hello world只输出hello这是截断和宽度的行为完全不同。这个差异我觉得挺反直觉的但记住浮点精度是补字符串精度是截就不会乱。对齐用-%-5d让内容靠左右边补空格。默认是右对齐这在拼日志表格的时候很有用。举个例子我要拼一个对齐的输出char line[64]; sprintf(line, %-8s|%6d|%8.2f, sensor, 42, 3.14159); // 结果: sensor | 42| 3.14宽度8左对齐的字符串、宽度6右对齐的整数、宽度8保留2位的浮点拼出来是整齐的三列。手写循环做这个至少要二十行还可能算错。这里有个细节值得提醒宽度可以用*动态指定比如%*d然后参数里依次传宽度和值。这在需要动态对齐的报表场景很有用但可读性会下降我一般只在不固定列宽的地方用。实操心得补零用于编号、时间、校验码这类场景比如%06d生成000042这种固定长度的ID方便后续按定长解析。别在普通数值上用补零会让人误以为是字符串。3.3 返回值与截断行为一个被严重低估的细节sprintf返回实际写入的字符数不含\0。这个好理解重点是和snprintf的对比因为这是最容易出错的地方。snprintf返回的是如果缓冲区足够大本该写入的长度而不是实际写入的长度。也就是说发生截断时返回值会大于你给的缓冲区大小减去1。这个设计有它的道理——你可以根据返回值判断需要多大缓冲区从而动态分配或二次调用但代价是不能直接拿返回值当实际长度用。我见过这样的代码char buf[16]; int n snprintf(buf, sizeof(buf), %s, long_string); // 然后按 n 长度处理 buf错了如果long_string有100字节n会返回100但buf里只有15个字符加一个\0。按n去读buf越界了。正确做法是用n sizeof(buf)判断是否截断实际长度用strlen(buf)或min(n, sizeof(buf)-1)。sprintf则没这个问题——它不截断所以返回值就是真实长度前提是你没溢出。但反过来说它没截断就是它危险的根源。这两者之间的取舍本质是安全但要多判断和简单但不安全的取舍。还有一个实用技巧把返回值存起来后面可以直接用省一次strlen。比如拼完字符串要追加直接把指针偏移到buf n继续写效率比反复strlen高。这种写法在拼长报文的时候很常见char buf[256]; int n 0; n sprintf(buf n, header:%d;, ver); n sprintf(buf n, len:%u;, len); n sprintf(buf n, data:%s, payload);这段代码读起来有点炫技但要清楚前提是你已经确认过总长度不会超过256否则buf n会越写越远。我在项目里用这种写法时一定会在旁边写一行注释标明最大长度估算防止后面有人加字段加到溢出。3.4%s与%n的两个特别注意事项%s看着最无害其实是溢出高发区。因为字符串长度完全由内容决定你写char buf[32]格式串是name: %s传入一个50字符的名字直接溢出。这类问题在测试时不容易发现因为测试数据通常短上线遇到长数据才炸。我的处理方式是涉及%s时要么在格式串里限制长度%.20s要么用snprintf并把缓冲区大小算进去。%.20s这个写法很实用——它保证最多只取20个字符即使传入的字符串更长也不会溢出只要剩下的部分长度可控。这在拼日志时特别合适比如打印用户输入的前若干字符。%n是个特殊说明符它不输出内容而是把目前已写入的字符数写回对应参数指向的int。功能上可以用来统计长度但它有严重的安全隐患可以被用来写内存所以现代编译器和安全规范基本都禁用它。我的建议很简单不要用%n需要长度用返回值就行。还有一个组合要小心%%输出百分号是安全的但如果你动态拼接格式串比如从配置读取格式一定要校验里面没有意外的%否则可能触发未定义行为。动态格式串本身是个反模式我基本不这么写。注意格式串和参数数量必须严格对应。多传参数通常无害被忽略少传参数会读到栈上垃圾值行为不可预测。编译器-Wformat能查一部分建议开启。4. 实操过程与核心环节实现4.1 环境准备与最小可运行示例先把环境说清楚这个很重要因为不同平台行为有差异。编译器用GCC或Clang都行建议开启警告gcc -Wall -Wextra -Wformat2 -o demo demo.c-Wformat2会把格式串和参数类型的匹配检查开到较严的级别能提前抓出%d对double这类错误。MSVC对应的是/W4也能查一部分。这个编译选项我强烈建议常开它是成本最低的防线。最小示例从一个完整的小程序开始覆盖几种常见用法#include stdio.h int main(void) { char buf[128]; int count 42; double volt 3.14159; const char *name sensor_a; int n sprintf(buf, %s: count%d, volt%.2f, name, count, volt); printf(result[%s]\n, buf); printf(length%d\n, n); return 0; }输出是result[sensor_a: count42, volt3.14]长度34。n可以直接当长度用因为sprintf的返回值就是实际写入数。这里算一下缓冲区该开多大字符串sensor_a是8: count是842最多11含负号, volt是73.14按double最大可能……其实浮点格式化后的长度不好精确估保守按整数部分3位小数点2位小数符号可能的溢出表示算留20字节余量。总的128是绰绰有余的。这种逐段估算再加余量的方法就是sprintf安全使用的核心心法。4.2 参数计算过程实录一次缓冲区大小的完整推导光说方法不够具体我拿一个实际场景完整走一遍。需求生成文件名格式为log_YYYYMMDD_HHMMSS_序号.txt序号最大9999。逐段列出来算log_4字节YYYY4字节MM2字节DD2字节_1字节HH2字节MM2字节SS2字节_1字节序号最大4字节9999.txt4字节结尾\01字节加起来是29字节。取整开32留3字节余量。如果有人后来改了序号...等一下这里有个真实的坑如果有人后来把序号改成最大999994字节就变5字节了缓冲区就不够了。所以我在代码里会加一个静态断言或者注释标明这个数字的依据。更好的做法是用宏定义各段长度让改动集中在一处#define SEQ_MAX_LEN 4 char filename[48161SEQ_MAX_LEN41]; sprintf(filename, log_%04d%02d%02d_%02d%02d%02d_%04d.txt, year, month, day, hour, min, sec, seq);%04d和%02d保证了定长这一点很关键——如果依赖数值本身的位数长度就是变的估算就没法精确。用补零强制定长缓冲区大小才有确定的上界。这个技巧我在做协议报文时用得最多所有字段都定宽整个报文长度就是常数安全性和可解析性都上去了。实际运行验证一下year2024, month3, day15, hour9, min5, sec7, seq42输出log_20240315_090507_0042.txt数一下是29个字符加上\0正好30缓冲区32够用。4.3 三种典型场景的完整实现场景一数值转字符串并按定长补零。这个需求在生成订单号、设备编号时非常常见char code[16]; sprintf(code, %010d, 12345); // 输出 000001234510位定长这里为什么用补零而不是补空格因为后续如果需要按定长切分解析补零能保证长度恒定补空格在传输过程中可能被截掉尾部空格导致长度变化。这个细节在跨系统交互时特别要注意。场景二十六进制输出做协议调试时必备unsigned char data[] {0xDE, 0xAD, 0xBE, 0xEF}; char hex[32]; int off 0; for (int i 0; i 4; i) { off sprintf(hex off, %02X, data[i]); } // 输出 DEADBEEF%02X保证每个字节两位不足补零。如果写成%X0x0A会输出A而不是0A解析的时候就对不上位置了。这类定宽十六进制的写法我在做数据抓包分析时天天用。缓冲区32是安全的因为4个字节最多8个字符加\0。场景三浮点格式化与精度控制。浮点是最容易出意外的地方char val[32]; double v 0.1 0.2; // 经典的浮点误差 sprintf(val, %.10f, v); // 0.3000000000 sprintf(val, %.20f, v); // 0.30000000000000004441 sprintf(val, %g, v); // 0.3这段值得细说。0.1 0.2在二进制浮点下不等于0.3打印10位看着正常打印20位就露馅了。这不是sprintf的错是浮点表示本身的局限。所以做数值输出时精度要按实际需要给别盲目给高精度否则用户会看到一堆本不该出现的尾数。%g会自动选更紧凑的表示适合日志%.2f适合金额——但金额其实更建议用整数分单位存储这是另一个话题了。实操心得缓冲区开多大我通常按最大可能长度 32来给这32是留给极端情况比如浮点变成inf、nan或者数字位数算错的余量。宁可浪费几十字节也不要冒溢出的风险内存现在没那么金贵。4.4 与snprintf的切换什么时候必须换前面说过原则这里给具体的切换动作。凡是满足以下任一条件的我会立刻换成snprintf格式串里有%s且来源不可控用户输入、配置、网络数据缓冲区大小是动态的或者接近临界值代码要长期维护、多人协作防的是别人加字段切换本身很简单加一个长度参数char buf[64]; // 原来 sprintf(buf, user%s, id%d, username, uid); // 改成 snprintf(buf, sizeof(buf), user%s, id%d, username, uid);但要注意两点。第一sizeof(buf)只在buf是真数组时有效如果buf是函数参数已退化为指针sizeof拿到的是指针大小8不是缓冲区大小。这个坑非常经典我见过不止一次。正确做法是把长度一起传进来或者用宏封装。第二截断的处理。snprintf截断后内容是能放多少放多少可能截在半个多字节字符中间中文场景也可能截成一个看起来正常但语义不完整的字符串。所以截断要判断int n snprintf(buf, sizeof(buf), user%s, username); if (n (int)sizeof(buf)) { // 发生截断需要记录告警或扩大缓冲区 }这个判断我一般会加上尤其是日志里截断丢信息比直接报错更难查。有些项目会封装一个带检查的宏把n size的情况上报我觉得这个做法值得抄。还有一个替代思路先用snprintf(NULL, 0, ...)算出所需长度再malloc。这个技巧在做动态拼接时很有用int need snprintf(NULL, 0, %s/%s, dir, file); char *full malloc(need 1); snprintf(full, need 1, %s/%s, dir, file);snprintf在size为0时不会写任何东西只返回所需长度这是标准规定的行为。这样两遍调用的写法比拍脑袋估一个应该够大的缓冲区靠谱得多代价是多一次格式化计算。路径拼接、SQL构造这类长度不好估的场景我倾向用这种方式。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因排查方法解决输出乱码、数字变成奇怪的值格式符与参数类型不匹配开-Wformat2看警告对照类型表改正程序莫名崩溃或改坏其他变量缓冲区溢出用长数据测试、开-fsanitizeaddress扩大缓冲区或换snprintf64位平台打印的数值被截断长度修饰符漏写检查%u是否该为%zu/%llu补长度修饰符snprintf后取长度越界把返回值当实际长度打印返回值与strlen对比用n size判断截断中文输出出现奇怪字符截断在多字节字符中间 / 编码不一致检查源文件与输出端编码避免按字节截断中文字符串浮点显示不精确精度给太高 / 浮点本身误差降低精度或用整数存储按业务需要设精度十六进制长度不对用了%X而非%02X看是否缺前导零加宽度和补零标志这张表里的每一条我基本都在实际项目里遇到过。尤其第一条和第二条占了绝大多数。5.2 三个真实踩坑记录的复盘第一个坑是类型不匹配。当时做传感器数据上报代码是sprintf(buf, temp%d, temp)而temp是float。编译只给了个警告当时没开-Wall运行后输出的数值毫无规律一会儿正一会儿负。原因很简单float在变参中提升为double占8字节%d只读4字节读到的内容完全不是那个数。修复就是改成%.2f。这个坑教我的第一件事是开警告第二件事是变参函数没有类型检查全靠自己。第二个坑是缓冲区计算漏了结尾。有段代码拼一个16字符的固定报文缓冲区开了char buf[16]格式串恰好写满16个字符没有给\0留位置。函数写完之后\0写到了缓冲区外面把相邻的一个变量低字节清零了。那个变量是状态标志被清零后程序进入了错误分支。这种问题靠单步调试都很难发现因为出错点和使用点隔得很远。后来我养成的习惯是估算长度时永远把\0算进去宁可多留一个。第三个坑是sizeof用于函数参数。我封装了一个日志函数参数是char *buf里面用snprintf(buf, sizeof(buf), ...)。sizeof(buf)拿到的是指针大小8于是每次只写7个字符就被截断日志全是残句。这个错误的隐蔽性在于代码看起来很标准snprintf、sizeof都用对了样子但语义是错的。修复是把长度作为参数传进来或者用宏在调用点展开、利用sizeof的真实数组大小。这个模式后来我统一改成了宏封装加_Static_assert检查。5.3 检测手段把问题在写完之前抓出来光靠眼睛看代码是靠不住的我现在的做法是加两道自动防线。第一道是编译警告加静态检查。除了-Wall -Wextra -Wformat2还可以上一些静态分析工具它们能查出缓冲区可能溢出格式串参数不匹配这类问题。把警告当错误处理-Werror也是个好习惯虽然一开始会改一堆代码但改完之后整体质量明显提升。第二道是运行时的检查。调试阶段我会用内存检查工具跑一遍它能在越界发生的瞬间定位到具体位置比事后排查效率高一个数量级。这对sprintf这种越界了也不一定立刻崩的函数尤其有价值。虽然它拖慢运行速度但只在调试时开不影响发布。还有个小技巧写一个自己的包装宏在调试版本里检查长度发布版本里去掉。比如#ifdef DEBUG #define SAFE_SPRINTF(buf, ...) do { \ int _n snprintf(NULL, 0, __VA_ARGS__); \ if (_n (int)sizeof(buf)) { \ fprintf(stderr, overflow risk at %s:%d\n, __FILE__, __LINE__); \ } \ } while (0) #endif这个思路不是要替代正确的写法而是在开发期多一层网。它不能捕获所有情况比如buf是指针时就失效了但对数组形式的缓冲区很有用。5.4 几条不那么文档化的经验关于性能sprintf比手写拼接慢但绝大多数场景下这点开销可以忽略。我做过一个粗糙的对比拼同样长度的字符串sprintf比纯memcpy加手写转换慢几倍。但如果这个操作每秒只做几千次那这点差异完全不影响只有在你用性能分析工具确认它确实是热点时才值得优化。过早优化是另一种坑。关于可读性一段复杂的格式串不如拆成几行snprintf追加。我见过一个%s套十几层的格式串改一个字段要数半天。可读性和正确性其实是一回事——看不懂的代码改错的概率就高。关于日志里的字符串日志中拼用户数据永远用%.Ns限长。日志本来就不是完整数据归档截断反而更安全而且能防止超长日志把磁盘写满或者把日志系统打挂。这个做法在线上救过我一次。关于中文中文字符在UTF-8下是多字节按%.Ns截断可能截在半个字符中间输出乱码。如果内容含中文要么不截断、保证缓冲区足够要么用能识别字符边界的处理方式。这个细节在处理用户昵称、备注这类字段时尤其要注意。6. 我个人的使用习惯与几点提醒写到这里把我在实际项目里沉淀下来的几条习惯说一下供你参考。第一条缓冲区大小不写裸数字用宏定义或者sizeof推导并在旁边注明这个数字怎么来的。我现在的代码里只要涉及sprintf那个缓冲区定义上方一定有注释写着各段最大长度的估算依据。这不是形式主义我吃过亏——隔了半年回来加一个字段忘了缓冲区是卡着边算的直接溢出。第二条格式串和参数列表尽量写在同一行或者紧挨着。拆得太开改参数时容易漏改格式串。这个看起来是格式问题实际上是正确性问题。我见过格式串在上一行、参数在下一行、中间隔了两行的写法维护起来非常痛苦。第三条涉及固定格式的时间、编号、协议字段优先用补零定宽%04d、%02X让输出长度成为常数。这样缓冲区大小就有确定上界安全性从估计变成证明。这一条对需要解析的场景还额外有好处——定长字段可以按固定偏移切解析代码也简单了。第四条养成能截断就用截断的判断凡是外部来的字符串格式串里加%.Ns限制最大读取长度。这个动作只是一次按键的事但能挡住大多数由于输入超长导致的溢出。我一般给日志类字段限32或64给标识符类字段限64或128具体看业务。最后一点想说的是sprintf这类函数的正确用法其实是建立在你知道自己在干什么之上的。它不是坏函数它的危险来自它把边界责任完全交给了调用者。你把边界算清楚、把类型对好、把外部输入限住它用起来又快又干净你偷懒不做这些它也不会当场报错只会在某个意想不到的时候给你一下。所以与其纠结用不用它不如把上面那几个基本功练扎实——这才是真正的护身符。如果你现在的项目里还大量用着没做边界控制的sprintf我的建议是先开编译警告把格式串和参数类型不匹配的清理掉然后再逐个评估哪些地方缓冲区不够。分两步走改动可控也能逐步体会到算长度这件事的价值。

C语言sprintf格式化输出：格式串、缓冲区溢出与snprintf

相关推荐

LLM如何成为专业软件工程中的可信协作者

Agent判断器选型与部署：Laya与Jev对比实战

OpenClaw部署指南：Node.js环境配置与多平台安装详解

更多资讯

QT for webassembly

C++仿C#实现事件处理

HarmonyOS 开发

C++ 机器学习 dlib 实践

C++ 有向图拓扑排序算法

PIC18F57K42与MAX14431的SPI隔离方案设计与实践

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？