r188863 - Issue fixits replacing invalid character literals with the equivalent \xNN

Eli Friedman eli.friedman at gmail.com
Wed Aug 21 12:03:30 PDT 2013


On Wed, Aug 21, 2013 at 9:18 AM, Richard Smith <richard at metafoo.co.uk>wrote:

>
> On 20 Aug 2013 21:15, "Nick Lewycky" <nicholas at mxc.ca> wrote:
> >
> > Author: nicholas
> > Date: Tue Aug 20 23:10:58 2013
> > New Revision: 188863
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=188863&view=rev
> > Log:
> > Issue fixits replacing invalid character literals with the equivalent
> \xNN
> > escape code.
> >
> > Added:
> >     cfe/trunk/test/Lexer/char-literal-encoding-fixit.c
> > Modified:
> >     cfe/trunk/lib/Lex/LiteralSupport.cpp
> >
> > Modified: cfe/trunk/lib/Lex/LiteralSupport.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/LiteralSupport.cpp?rev=188863&r1=188862&r2=188863&view=diff
> >
> ==============================================================================
> > --- cfe/trunk/lib/Lex/LiteralSupport.cpp (original)
> > +++ cfe/trunk/lib/Lex/LiteralSupport.cpp Tue Aug 20 23:10:58 2013
> > @@ -978,7 +978,7 @@ CharLiteralParser::CharLiteralParser(con
> >    uint32_t largest_character_for_kind;
> >    if (tok::wide_char_constant == Kind) {
> >      largest_character_for_kind =
> > -        0xFFFFFFFFu >> (32-PP.getTargetInfo().getWCharWidth());
> > +        0xFFFFFFFFu >> (32 - PP.getTargetInfo().getWCharWidth());
> >    } else if (tok::utf16_char_constant == Kind) {
> >      largest_character_for_kind = 0xFFFF;
> >    } else if (tok::utf32_char_constant == Kind) {
> > @@ -1009,7 +1009,13 @@ CharLiteralParser::CharLiteralParser(con
> >          unsigned Msg = diag::err_bad_character_encoding;
> >          if (NoErrorOnBadEncoding)
> >            Msg = diag::warn_bad_character_encoding;
> > -        PP.Diag(Loc, Msg);
> > +        std::string escaped =
> llvm::utohexstr(static_cast<uint8_t>(*start));
>
> Are we guaranteed that the character is >= 0x10 here? (utohexstr might
> otherwise produce only one character).
>
>
> Yes... it's guaranteed to be >= 0x80, actually.   But it would probably be
a good idea to make the code clear anyway.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130821/e451ae24/attachment.html>


More information about the cfe-commits mailing list