[PATCH] [PATCH] Proposed alternative to llvm::format()
Sean Silva
chisophugis at gmail.com
Wed Sep 17 20:14:33 PDT 2014
This is the approach I've always wanted ever since I experienced YAMLIO's
Hex* classes. I can never remember the right printf format specifiers for
width and stuff (not to mention the iostream manipulators), and the PRI*
macros are ugly and error-prone.
Also you're not the only one running into these issues: llvm::format, such
as r185766 and PR20715. I also seem to remember one more, but I can't find
it.
The argument could be made that we should improve clang's printf checking
to handle things like the snprintf in the function template like what
llvm::format uses, but I think that's orthogonal.
-- Sean Silva
On Wed, Sep 17, 2014 at 7:34 PM, kledzik at apple.com <kledzik at apple.com>
wrote:
> Hi rafael, silvas,
>
> In using llvm::format() to dump columnar tables of data in my recent
> enhancements to llvm-objdump, I ran into some issues uncovered by the built
> bots that show how unsafe llvm::format() is. The issues I hit where that
> the compiler did not check that %x match the integer size and that %s can
> match a StringRef but produce the wrong output. %s is also ugly with
> StringRef values because you have to convert to a std::string then call
> c_str().
>
> All I really needed was a way to generate fixed with hexadecimal (e.g.
> 0x00001234) and fixed with strings (e.g. right or left justified strings in
> a column). I whipped up an alternative that is easy to use with the stream
> operator and generates fixed with output.
>
> If there is interest in this, I can clean it up and add some test cases.
> Or perhaps there already is some good technique for fixed width
> formatting. This patch also contains examples changes in llvm-objdump to
> use this new functionality.
>
> http://reviews.llvm.org/D5390
>
> Files:
> include/llvm/Support/Format.h
> include/llvm/Support/raw_ostream.h
> lib/Support/raw_ostream.cpp
> tools/llvm-objdump/MachODump.cpp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140917/bfc28ab3/attachment.html>
More information about the llvm-commits
mailing list