The "%#o" formatting string isn't handling the value of 0 properly. '0' should be formatted as '0', not '00'. # stap -gve 'probe begin { x = sprintf("%#o", 0); printf("%s\n", x) }' Pass 1: parsed user script and 86 library script(s) using 149332virt/24016res/2860shr/21924data kb, in 140usr/60sys/205real ms. Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 149860virt/24764res/3112shr/22452data kb, in 10usr/0sys/6real ms. Pass 3: translated to C into "/tmp/stapRQJcEh/stap_0612925ba7f9e19831f534939ef39418_706_src.c" using 149860virt/25052res/3376shr/22452data kb, in 0usr/0sys/2real ms. Pass 4: compiled C into "stap_0612925ba7f9e19831f534939ef39418_706.ko" in 3760usr/1410sys/5145real ms. Pass 5: starting run. 00 Pass 5: run completed in 30usr/100sys/2140real ms. (This is causing a failure in the nd_syscall.exp testcase for umask, because the nd_syscall probe uses the 'returnstr' function, which uses the kernel's snprintf() function which correctly handles 0.)
(In reply to comment #0) > The "%#o" formatting string isn't handling the value of 0 properly. '0' should > be formatted as '0', not '00'. [...] > (This is causing a failure in the nd_syscall.exp testcase for umask, because > the nd_syscall probe uses the 'returnstr' function, which uses the kernel's > snprintf() function which correctly handles 0.) Seems like just a difference of opinion to me. We also print %#x,0 as 0x0, which I know differs from glibc, but I'm not sure what the kernel does with that. We could just as well flip this that returnstr() ought to be using stap's own formatting functions for consistency...