On Feb 12, 2014, at 9:36 AM, Tom Browder wrote: >>> On a related note, I get a failure on test 66 even after the revert back to >>> %d, >>> so you seem to have exposed another consistency issue as well. Testing >>> printf directly, I get: >> >> Hm, I don't know why I didn't, but 'I'm checking it. I'll add another >> test that uses a number so the padding will be tested.
Sorry I wasn't more clear. Basically, stdc nor posix define behavior for "%0*s" as a print specifier so a compiler can do whatever they want. > However, I do get the warning (using -W): > > '0' flag used with '%s' gnu_printf format [-Wformat] This is the issue. The POSIX spec (i.e., http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html ) specifically says it's undefined, so that's our answer. > I can't explain our different results. I don't think we need to. Just the notion that two different implementations of printf produce different results means we cannot regression test that behavior. We can only define a behavior, hopefully one that makes sense. Considering what the zero means in other contexts, I'd actually expect it to pad with zero (not spaces) but we could just as well issue an error or pad spaces. Basically, doesn't matter. We should remove that test. :) Cheers! Sean ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
