[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