起因是酱紫的：
有个学弟给他的学弟出了一道题：
题目描述：
下面是用阿姆斯特朗加密算法加密后的一串数字，解密它！数字内容（2032951656 1629517167 1981834610 544830053 1685024615 0）
关于阿姆斯特朗回旋加速喷气式阿姆斯特朗加密算法的第一步：
该算法首先读入一段文本，该文本的每个字符仅占1字节，直到结束。
然后，该算法会将连续的每4个字节的二进制位按逆序连接，凑成一个整数，并在末尾加0。例如：
读入：
abcdefgh
（二进制：01100001(a) 01100010(b) 01100011(c) 01100100(d) 01100101(e) 01100110(f) 01100111(g) 01101000(h)）
转换后：
1684234849 1751606885 0
（二进制：01100100011000110110001001100001 01101000011001110110011001100101 0）
（01100100(d)01100011(c)01100010(b)01100001(a) 01101000(h)01100111(g)01100110(f)01100101(e) 0）
请编程输出答案
无输入，输出结果
某学弟是酱紫做的：
然后一个数一个数的跑，并且手动记录答案
且不说他那一堆左移右移的操作，我第一眼看到的最大的问题是在printf那里，%c对应到了long long int上，常理来说应该会出异常，但是他却把结果正常输出了，于是猜测是不是printf有啥神奇的黑科技，于是模拟了一个printf，其实就是写了个动态参数的函数，然后一个字节一个字节的输出调用栈的内容。比如n是1684234849 的时候，d理想状态是'a', c => 'b', b => 'c', a => 'd'，并且我之后的假设全部基于此，并且蛋疼就蛋疼在我这个理想状态上。
这是理想状态的堆栈示意图，但是实际上我的输出显示堆栈是下边那个样子，误以为是函数在压栈的时候对数据进行了压缩，这个问题我找了几个dalao讨论了半天也没有讨论出啥，后来请教了下猫总。猫总原话：“调试的时候直接看stack的内存”，然后咱就打开了vs，然后我注意到了红框里的那个：
abcd....bcd.....cd......d.......
时光鸡，光鸡，鸡，
我qndyd
到这我才恍然大悟，d的内容是0x00 00 00 00 64 63 62 61
printf接收到的参数实际是酱紫的：
正好四个%c对应了d的前四个字节
至于d为啥没有按照理想情况结果是0x61，因为他是long long int啊~
啊！