刚刚和舍友打赌。舍友说PY20行能做xlsx文件分析整理,C20行屁都干不了。我说简单的cat还是能做的嘛。他说不信。我说不处理非文件的参数的话10行能做啊。
下面直接贴代码吧:
#include <stdio.h>
#include <stdlib.h>
#define assert(x) ((void)((x)||(perror(argv[0]), exit(-1), 0))) //<update171106
int main(int argc, char *argv[]) {
int ai = 1;
do {
if (argc > 1) assert(freopen(argv[ai], "rb", stdin)); //<debug
for (int c; (c = getchar()) != EOF; putchar(c)) //<update180305
;
assert(!ferror(stdin));
} while (++ai < argc); //<debug
}
Feature
- 允许多个文件合并
- 允许从标准输入输入
- 有错误反馈
运行截图:
debug
mdzz 之前些地方写错了:
13行 } while (ai++ < argc);
应该是++ai。这里参数argc
指的是argv
数组成员个数(标准要求argc >= 0 && argv[argc][0] == '\0'
)
9行 if (argc != 1) assert(freopen(argv[ai], "rb", stdin));
应该是argc > 1
。
这两个错误会导致:
- 如果目标环境不提供命令行参数,即
argc == 0
的时候,可能会导致freopen的第一个参数解析时越界,出现不可预知的状况。 - 如果调用时带参数,会导致最后一次循环
ai == argc
,间接导致freopen的第一个参数为空串。
2运行结果错误的演示:
这里最后一次freopen接收到空串,这个freopen的表现和传递NULL一样(不合理,我看POSIX标准没找到这点,反而找到了ENOENT: pathname is an empty string <- 感觉原文有二义性)
为什么我记得空串代表原本的stdin呢?
update171106:
今天有瞄了下代码,感觉那个宏不太对劲,好像加上个抛弃返回值的强制转换比较合适。
否则可能会被用来做奇怪的事情(因为返回 ((_bool)1)
):
- 后跟数组下标
assert(true)["string233"]; => "string233"[1] => 't' - 前跟函数指针(函数名)
pFun assert(true); => pFun(1) - 前跟 if while
if/while assert(true) => if/while (1)
加上 (void)
就能防止被上面那么说的乱用啦 233,然而没什么意义 hh
assert 函数宏
解释一下这个函数宏吧:#define assert(x) ((void)((x)||(perror(argv[0]), exit(-1), 0)))
首先这个宏没有副作用(因为所有参数有且只有出现一次)。
其次这个东西还是用了不少 C 技巧的:
||
短路特性,只有参数(_bool)x == false
才执行后面的逗号运行符;见 std-keyword: sequence point & short-circuit evaluation
,
逗号运算符顺序执行的特性,所以先执行perror
再执行exit
。因为 || 运算符要求运算符两边都是标量,所以在最后让逗号表达式返回一个 int。perror(argv[0])
argv[0] 是程序的调用名字,这个输出是很标准的 linux 程序做法。
update180305:
原本那个 getchar 的循环原本是这样写的:for (char c; (c = getchar()) != EOF; putchar(c))
,这段代码有明显的错误。
错在哪?当然是char这里了:如果用char的话,在“实际应用”中会导致0xFF
和EOF
的重合。
实际上很多 C 环境的 char
都是 int8_t
,而 (int8_t)0xff
很明显是 -1
,不相信?那就试试下面的 C11 代码能不能通过编译。
// test.c
// clang -Wall -Wextra test.c -c -o cat
#include <stdint.h>
_Static_assert((int8_t)0xff == -1 && sizeof(char) == sizeof(int8_t), "it's impossible meet error!");
_Static_assert((char)0xff != -1, "in this env., char is signed!");
结果如下:
我们来分析一下
编译不通过 ->
静态断言失败 ->
(char)0xff == -1 ->
(char)0xff 算数提升到 int,且值等于负一 ->
(char)0xff 符号位扩展了 ->
(char)0xff 等价于 int8_t
所以如果一个二进制文件内有 0xff
这个字节的话,原本代码会导致误判,以为到了 EOF
而提前结束。
改成 int
就能在实际应用中避免这个问题,这也是标准函数原型这样设计的本意。
注意:二进制文件才会有这样的问题, ascii
编码文本文件没有 0xff
。
然而这里还是有一个问题,标准只要求了 sizeof(char) <= sizeof(int),会不会有一些很 gay 的环境,他们两者相等,那就无法预留一个 EOF 的值出来了,所以这个标准的原型严格的说还是存在问题的。
不过如果真的有这种环境,那在这之上很难实现通用的文件就是了。
欢迎转载©️tjua link: http://www.cnblogs.com/tjua/p/7758047.html (请保留本行)
next target: 基于 make 的简易自动构建系统
最近看到 gitlab-runner 项目后想到的脑洞。估计也是几行的事。