fmt::Pointer padding

[richo]

This pads out the printing of pointers to their native width.

Extracted from and rebased on top of #24144

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

This isn't the behavior that I would personally expect from these routines, could you explain a little bit more about why you'd like to make this change?

[richo]

Yeah, so this morning I did a little more poking, and discovered that I was misremembering what printf("%p".. does in C. If the goal is to continue to do what C does, then I'm perfectly happy to just close this.

In general, I find that 99% of the time I'm printing a pointer is because I'll copypaste it elsewhere (generally a python repl), do some math on it, then do something with it elsewhere. Given this workflow, padding them all to the native pointer width of the platform cases them to line up neatly, make it easy to eyeball if you have a bunch of values all on page boundaries, etc.

The rationale for the change is pretty much entirely that I would assume this will only be used in debugging, and for that usecase, padded pointers seem much more user friendly to me.

[alexcrichton]

With the debug builders work @sfackler has been doing the # flag to formatting is starting to mean "debug mode", so another option would be to gate this form of formatting based on that flag being present or not.

[richo]

My personal preference would be this, but making {#:p} invoke this behaviour would be totally agreeable. Has his work landed?

[alexcrichton]

It should actually just be as simple as checking for Alternate in the flags of the formatter whenever you're coming in to formatting a pointer. In that sense {:#p} should work just fine today (it just doesn't do anything based on the # flag)

[richo]

Oh, amazing. I did wonder why the current code sets Alternate unconditionally, but didn't rock the boat.

I'll update the PR when I get a sec.

EDIT: While I'm asking questions, do I need to unfrob the flags on the way back out? It wasn't very clear to me.

[richo]

I think this is good to go, r? @alexcrichton

Preempting your nit, the body of the Pointer formatter is kinda awkward. I considered adding a PrefixBaseChar flag, which would avoid needing to hijack Alternative. Happy to do that if you think it's worthwhile.

[alexcrichton]

Wherever possible I tend to prefer if cfg!(...) over #[cfg], and it looks like for all uses of #[cfg] here the cfg!-based form would suffice?

[richo]

Sure. I guess the only correctness issue with it is that right now, if you build on a platform that doesn't have 32 or 64 bit wide pointers, it will explode violently.

Granted, there's no obvious sign of anyone trying that soon, but the most obvious cfg! based construction will silently skip a function call on such a platform. How defensive is it reaonable to be?

[alexcrichton]

I'm more worried that #[cfg] code isn't typechecked at all if it's for a different platform, often leading to really annoying cross-platform bugs.

[alexcrichton]

*compile errors

[alexcrichton]

One last #[cfg] here

[richo]

Ok, think we're finally good to go 🎉

[alexcrichton]

@bors: r+ 64da4e1

[bors]

⌛ Testing commit 64da4e1 with merge 97f1eab...

[bors]

💔 Test failed - auto-mac-32-opt

[alexcrichton]

@bors: retry

On Fri, Apr 10, 2015 at 4:49 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-mac-32-opt
http://buildbot.rust-lang.org/builders/auto-mac-32-opt/builds/4449

—
Reply to this email directly or view it on GitHub
#24186 (comment).

[bors]

⌛ Testing commit 64da4e1 with merge c87ec1e...