<p dir="ltr"><br>
>><br>
>> * I don't want to trade my time implementing stuff users will see (linker script, debug index, speed) for things users will not.<br>
><br>
><br>
> Don't you think that you are somehow trading your time for other people's time when they'll have to build other features on top of the codebase?<br>
> I understand you're putting the cursor toward end-users facing interface, but the reason I'm working on clang/LLVM in the first place is especially that care is given to what other developers will have to cope with in the project (while being somehow pragmatic as well to make forward progress "quickly").</p>
<p dir="ltr">I don't think I am trading other developers time in this. You can make that argument for things like global state (I still think the way we are doing it is more developer time efficient overall), but I don't think so for security.</p>
<p dir="ltr">>> * I don't want to pretend that cherry picking a few bound checks will make lld safe on untrusted input.<br>
><br>
> My impression is that there is a kind of "philosophical" view at stand: are we treating such crash as bugs and prioritize fixing them accordingly or not. I believe we had the same kind of philosophical disagreement with the development practices (no global state, etc.) a few months ago: while acknowledging that "perfect is the enemy of good", some long-term core principles can be set, and the development can tend toward these design goals, while still having some tradeoff for "getting things done" in a reasonable time.<br>
></p>
<p dir="ltr">I don't really think it is philosophical. Llvm is utterly inappropriate for a security context on its own. You need to get help from the OS or something like NaCl. Take a quick look at the work that went into securing libressl and imagine the same being done to llvm. What allocator would you start with?</p>
<p dir="ltr">With security out of the way, the question that remains is how visible a given issue is. It is critical for clang to handle broken code, since it is given broken code all the time. In an IDE it gets it almost at every keystroke.</p>
<p dir="ltr">It less important to gracefully handle things like the example I posted, just because it is far less likely to be hit.</p>
<p dir="ltr">A broken object file is orders of magnitude less likely.</p>
<p dir="ltr">Cheers,<br>
Rafael</p>