<div><div dir="auto">LGTM</div><div dir="auto"><br></div><div dir="auto"> Filipe</div><br><div class="gmail_quote"><div>On Thu, 6 Jul 2017 at 19:42, Kuba (Brecka) Mracek via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">kubamracek marked 3 inline comments as done.<br>
kubamracek added inline comments.<br>
<br>
<br>
================<br>
Comment at: lib/sanitizer_common/sanitizer_mac.cc:808<br>
+uptr GetTaskInfoMaxAddress() {<br>
+  integer_t vm_info[kTaskVmInfoCount] = {0};<br>
+  mach_msg_type_number_t count = kTaskVmInfoCount;<br>
----------------<br>
filcab wrote:<br>
> Shouldn't this be a `task_vm_info_data_t`? Or is that not available?<br>
> As far as I can tell, `integer_t` are `int`, and we're not guaranteed to have this array properly aligned for that `uptr` load.<br>
><br>
> If it's not available, I'm ok with a stub somewhere, but I'd make this either a properly-sized and aligned struct, or a `uptr` array (proper alignment, AFAICT) and cast its pointer when calling task_info.<br>
`task_vm_info_data_t` can't be used because we need to access a field that's only available in a new version of the SDK, and we still want to be able to build with the older SDKs.<br>
<br>
You're right about the int/integer_t/uptr confusion.  The new version should be more clear.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D35032" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35032</a><br>
<br>
<br>
<br>
</blockquote></div></div>