<div dir="auto">Sure, make your change and then update libffi!<div dir="auto"><br></div><div dir="auto">Victor</div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 23 mai 2017 18:19, "Steve Dower" <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23May2017 1212, Victor Stinner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2017-05-22 13:17 GMT-05:00 Steve Dower <<a href="mailto:steve.dower@python.org" target="_blank">steve.dower@python.org</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once the special protection is removed, most of these cases will become<br>
OSError due to the general protection against segmentation faults.<br>
</blockquote>
<br>
It didn't know that ctypes on Windows had a special protection against<br>
programming errors. I'm not aware of such protection Linux. If you<br>
call a function with the wrong number of arguments, it's likely to<br>
crash or return random data.<br>
<br>
I guess that the point is to help debugging. But since Python 3.6,<br>
faulthandler now registers a Windows exception handler and so it able<br>
to dump the Python traceback on any Windows exception:<br>
<a href="https://docs.python.org/dev/library/faulthandler.html#faulthandler.enable" rel="noreferrer" target="_blank">https://docs.python.org/dev/li<wbr>brary/faulthandler.html#faulth<wbr>andler.enable</a><br>
<br>
So I think that it's now fine to remove the ctypes protection. Just<br>
advice (remind? ;-)) users to enable faulthandler: python3 -X<br>
faulthandler, or call faulthandler.enable(). (You might want to use a<br>
log file for that on Windows, depends on the use case.)<br>
</blockquote>
<br>
faulthandler is already recommended in the docs, and the existing SEH protection for access violations will remain (since that is independent of libffi).<br>
<br>
I'll be honest, I have appreciated the functionality in the past, but it really isn't good practice and getting rid of it will be an overall benefit. Technically even the segfault protection isn't a great idea, since you really do end up in an unknown state with regards to memory page allocations, but it's better than crashing all the way out.<br>
<br>
Cheers,<br>
Steve<br>
</blockquote></div></div>