<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 28, 2017 at 10:31 AM, David Barto <span dir="ltr"><<a href="mailto:barto@cambridgesemantics.com" target="_blank">barto@cambridgesemantics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I’m going to disable (for the MacOS Builds) the memory limit checks for the time being.<div><br></div><div>Should I register a bug about this or is there someone with ‘more authority’ who would be more appropriate?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div></font></span></div></blockquote><div><br></div><div>AFAIK from this community you should feel free to open a bug.  If I were you that's what I'd do.  Maintainers are free to debate your (and my) claim that this is not how clang should behave.  The challenge will be coming to a resolution on how to address the problem, and perhaps finding leverage to get someone to execute the fix if you don't know how yourself.</div><div><br></div><div>The rich set of behavior that snaps into action when the compiler faults is beneficial to gathering bug reports from end users.  Preserving that functionality while making the signal handler robust/safe will require a smarter design.</div><div><br></div><div>As an aside it would be cool to write an analyzer rule that checks for exclusively signal-safe system calls that come from functions registered as signal handlers.</div><div><br></div><div>-Brian</div></div>
</div></div>