<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>In a majority of cases, char* is a pointer-to zero-terminated memory, and very rarely just a pointer to one char</div><div><br></div><div>The LLDB data formatter goes with the flow, and assumes that a char* is a zero-terminated string.</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style=" orphans: 2; widows: 2; border-collapse: separate; border-spacing: 0px;"><span style="font-size: 12px; orphans: auto; widows: auto;">Enrico Granata</span><br style="font-size: 12px; orphans: auto; widows: auto;"><span style="font-size: 12px; orphans: auto; widows: auto;">📩 egranata@</span><font color="#ff2600" style="font-size: 12px; orphans: auto; widows: auto;"></font><span style="font-size: 12px; orphans: auto; widows: auto;">.com</span><br style="font-size: 12px; orphans: auto; widows: auto;"><span style="font-size: 12px; orphans: auto; widows: auto;">☎️ 27683</span></div></div></div>
</div>
<br><div><div>On Jun 25, 2013, at 2:15 PM, Tim Northover <<a href="mailto:tnorthover@apple.com">tnorthover@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">Fix undefined behaviour in data formatter test -- ensure char*<br>null-terminated so LLDB does not read off the end of the array.<br></blockquote><br>Isn't that a real problem in the formatter? I suppose it's very difficult to<span class="Apple-converted-space"> </span><br>decide what to do since "char *" usually is a string. But still, the original<span class="Apple-converted-space"> </span><br>C++ wasn't undefined (at least in that aspect).<br><br>Tim.<br>_______________________________________________<br>lldb-commits mailing list<br><a href="mailto:lldb-commits@cs.uiuc.edu">lldb-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a></div></blockquote></div><br></body></html>