作者hpyhacking (骇人听闻)
看板C_and_CPP
标题[问题] printf 格式不同问题
时间Fri Oct 27 02:29:16 2017
开发平台(Platform): (Ex: Win10, Linux, ...)
win 10 用cygwin64
64位元
编译器(Ex: GCC, clang, VC++...)+目标环境(跟开发平台不同的话需列出)
GCC
额外使用到的函数库(Library Used): (Ex: OpenGL, ...)
no
问题(Question)：
简单的printf问题
int a = 10;
printf( "%f\n", a );
float w = 35.14;
printf( "%w d\n", w );
喂入的资料(Input)：
没有
预期的正确结果(Expected Output)：
预期第一个printf输出的是10.0
当然结果大家知道是0
想请问为甚麽这个型态错误印出的是0 ?
原本想说都是占4bytes应该会误打误撞可以显示好
爬到英文说跟甚麽IEEE有关？英文看不是很懂....
再来既然格式都一样错误
为甚麽第二个printf有印出东西但是是乱数，这个数是其他记忆体空间里的数字吗？
错误结果(Wrong Output)：
0 ( undefined? )
1073741824 ( 乱数 )
程式码(Code)：(请善用置底文网页, 记得排版)
补充说明(Supplement)：
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 42.72.57.150
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1509042559.A.2EE.html
1F：推 LPH66: 这问题会牵涉到不少这些 C 语言功能的实作细节10/27 02:34
2F：→ LPH66: 要完整回答会很长一串, 但一般写程式不需要考虑这些细节10/27 02:35
3F：→ kingofsdtw: google吧 :D10/27 02:35
4F：→ Schottky: 我觉得不好，我觉得这样写程式很危险，把 -Wall 打开吧10/27 02:41
5F：→ hpyhacking: 这是故意的 10/27 02:44
6F：推 a58524andy: 先读计概10/27 06:00
7F：推 peterwu4: 可以查一下float和int储存格式的差异~ 啊，你已经查了XD10/27 07:42
8F：→ peterwu4: 找中文的网页说明来看~10/27 07:42
9F：推 peterwu4: 0的部分比较好解释，因为浮点数小点的部分都是放在格式10/27 07:52
10F：→ peterwu4: 後面，整数的10，32bit的格式，後三个byte都是0，所以小10/27 07:53
11F：→ peterwu4: 数点的部分是零，乘什麽都结果都是零。同理去理解另一个10/27 07:55
12F：→ peterwu4: 部分吧~10/27 07:55
13F：→ peterwu4: 浮点数存的时候4个byte里都有东西，用整数读出来当然就10/27 07:57
14F：→ peterwu4: 是怪怪的数字了10/27 07:57
15F：→ vm0: 我实际在linux上用gcc跑,printf("%d\n",w)会是35,跟印象中一10/27 10:17
16F：→ vm0: 样,在宣告时就会自动省略小数,请教是为什麽呢?10/27 10:18
17F：→ nh60211as: 他要打double w = 35.14打错了吧10/27 10:22
18F：→ vm0: 原来如此,看前几楼回的还以为我哪里搞错了,谢谢10/27 10:41
19F：→ nh60211as: 我也不确定，照他的错误结果输入应该是浮点数才对10/27 10:56
20F：→ MOONRAKER: printf不依照格式字串检查变数格式。有错误结果自负。10/27 11:08
21F：→ hpyhacking: 先谢谢大家一声，还有我现在就是在读计概QQ10/27 12:07
※ 编辑: hpyhacking (42.72.57.150), 10/27/2017 12:15:03
22F：→ hpyhacking: 不好意思有打错的！！！ 10/27 12:15
※ 编辑: hpyhacking (42.72.57.150), 10/27/2017 12:17:13
23F：→ Schottky: 假如 printf 期望的 size 和变数 size 不一样会出大事 10/27 13:38
24F：推 ersfw4418: IEEE754 10/27 16:47
25F：推 yvb: 若是要 "正确的" 把 double "误" 当做 int 来印, 应该写做 10/27 20:42
26F：→ yvb: printf("%d\n", *(int *)&w); 结果 35.14 会是 -2061584302 10/27 20:42
27F：→ yvb: 而原 PO 的 printf("%d\n", w); 在 Linux 系统开了 ASLR 时, 10/27 20:43
28F：→ yvb: 甚至每次显示结果都不同, 真的像是乱数一般. 显然是 va_list 10/27 20:43
29F：→ yvb: 这个黑盒子中不知发生了什麽事. 10/27 20:43
30F：推 akasan: ABI 10/27 20:48
31F：推 AstralBrain: 以 amd64 来说, 浮点数 w 会进 xmm0 register 10/27 21:30
32F：→ AstralBrain: 然後 printf 从没使用的 rdi 读一个整数, 所以是什麽 10/27 21:31
33F：→ AstralBrain: 值都有可能 10/27 21:31
34F：→ PkmX: 楼上rdi应该是format string 所以下一个参数是rsi 10/28 15:45
35F：推 AstralBrain: 啊对... 忘了有 format string 10/29 06:08
36F：推 LPH66: 这里还要考虑可变参数, 我其实不太确定 amd64 的可变参数 10/29 09:13
37F：→ LPH66: 会不会用到浮点数暂存器... 10/29 09:13
38F：→ LPH66: 我所知的可变参数实作几乎都是全部推堆叠 10/29 09:13
39F：推 LPH66: 噢, 找到资料了, 即使是可变参数 amd64 一样会用暂存器 10/29 09:21
40F：→ LPH66: 那用了多少 xmm 暂存器传浮点数会以 al 传进去 10/29 09:23
41F：→ LPH66: 所以就是上面 Astral 讲的那个样子 10/29 09:23
42F：推 yvb: 其实我前面只是要指出, 原PO 的问题, 在 X86-64 的环境下, 10/30 00:46
43F：→ yvb: 并非单纯是 IEEE754 的问题, 照规则算出 "乱数" 会不符合; 10/30 00:47
44F：→ yvb: 当然, 若是在 i386 (32-bit) 的环境, 应该就会回归单纯了. 10/30 00:47
45F：→ yvb: 另外, 上面 regs 的推论, 会让人觉得在瞎子摸象, 可参考 10/30 00:47
47F：→ yvb: 此外, 依据 (1) 及其後 List 的 X86-64 段落, 我的测试使用 10/30 00:48
48F：→ yvb: Linux => System V AMD64 ABI, 但原PO 则为 Win10 cygwin64, 10/30 00:48
49F：→ yvb: 不知是会采用 SysV 还是 M$ X64 calling convention ? 10/30 00:48
50F：→ yvb: 有关 regs 的相关推论, 不知是否依旧完全符合? 10/30 00:49
51F：→ hpyhacking: 今天期中考完我再来研究一下 11/10 17:53