[Lldb-commits] [lldb] r184877 - Fix undefined behaviour in data formatter test -- ensure char* null-terminated

[Enrico Granata]

In a majority of cases, char* is a pointer-to zero-terminated memory, and very rarely just a pointer to one char

The LLDB data formatter goes with the flow, and assumes that a char* is a zero-terminated string.

This is exactly the behavior that the test case was showing, LLDB was reading memory and printing until the first 0 (byte value, not ASCII-encoded digit) is encountered - whether that memory is “random” or user-defined is not for LLDB to know (and how would we? short of having an oracle that knows the truth, we have issues finding out whether more elaborate data structures are valid or “random”, so guess how complicated, if even possible, that would be for a trivial C-style pointer-to-char)

As a safety measure, we will stop reading after a certain (user-configurable) amount of data has been ingested, but that’s all that will happen.

While I think that the test case was coping quite well with the randomness of the input, feel free to elaborate on why you feel there is a data formatters issue in this scenario

Enrico Granata
📩 egranata@.com
☎️ 27683

On Jun 25, 2013, at 2:15 PM, Tim Northover <tnorthover at apple.com> wrote:

>> Fix undefined behaviour in data formatter test -- ensure char*
>> null-terminated so LLDB does not read off the end of the array.
> 
> Isn't that a real problem in the formatter? I suppose it's very difficult to 
> decide what to do since "char *" usually is a string. But still, the original 
> C++ wasn't undefined (at least in that aspect).
> 
> Tim.
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130625/94d403a5/attachment.html>