[Lldb-commits] [PATCH] D77843: [lldb/DataFormatters] Delete GetStringPrinterEscapingHelper

Thu Apr 16 17:50:24 PDT 2020

vsk planned changes to this revision.
vsk added a comment.

Sorry for the delay, I plan to have an update for this soon.

In D77843#1978964 <https://reviews.llvm.org/D77843#1978964>, @JDevlieghere wrote:

> Have you asked the foundation people about the ASCII support in NSString?

No, I'm not sure what to ask. Having thought things over, I think my 'FIXME' about 'In practice, do we ever prefer ASCII-only formatting over UTF8 formatting?' was premature, so I'll delete it.

I did some experiments with forcing invalid data into an NSString and seeing what comes out of NSLog. Both with `dataUsingEncoding:NSASCIIStringEncoding`, or with just typing in invalid bytes, NSLog just prints an empty string (in the latter case -WCFString-literal even warns that input conversion is stopped after an invalid byte is seen). I don't think it'd be helpful for lldb to match that behavior? At least, we don't match that behavior today, we try to escape and print out the invalid bytes.

If we want to continue to not match NSLog's behavior, then I think we should we treat invalid bytes under ASCII vs. utf differently (we can print the actual character in the utf case, and a sequence of '\x..\x..' otherwise).

================
Comment at: lldb/source/DataFormatters/StringPrinter.cpp:259
+  case StringPrinter::EscapeStyle::Swift:
+    // Prints up to 14 characters, then a \0 terminator.
+    escaped_len = sprintf((char *)data, "\\u{%x}", (unsigned)codepoint);
----------------
shafik wrote:
> Maybe I am missing something but I don't think the `sprintf` below can go up to 14 chars.
You're right, I got %x mixed up with %u.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77843/new/

https://reviews.llvm.org/D77843