<div dir="ltr">IIUC we cannot change the existing on-disk struct layout once it's submitted. Otherwise multiple incompatible "V1" files will be created out there, which cannot be read properly by the LLD. I think that's why we version file structures. The way to keep the backward compatibility is to define a new struct as a new version, make the writer to emit in the new format, while keeping the reader to be able to read both from the previous and from the current formats. Native format is designed to be able to make such transition.<div>

<br></div><div>If you are thinking that we are not at the stage to care about backward compatibility, and breaking the compatibility of V1 format is okay, I think that might make sense, though. I doubt there's someone who actually has Native files on disk. Is this your point?</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 11:58 AM, Shankar Kalpathi Easwaran <span dir="ltr"><<a href="mailto:shankarke@gmail.com" target="_blank">shankarke@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  The targetIndex should be 32bits in NativeReferenceIvarsV1. This should fix it I assume right ?<br>
<br>
  I am not sure why the compiler is not issuing a warning of using a lower type on the lhs versus a higher type used with the map with typedef llvm::DenseMap<const Atom*, uint32_t> TargetToIndex, function getTargetIndex.<br>


<br>
  May be there was a different reason of having the V2 struct ?<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D2217" target="_blank">http://llvm-reviews.chandlerc.com/D2217</a><br>
</blockquote></div><br></div>