On 23/03/15 19:46, Nicolas George wrote:
> I will trim the discussion somewhat.
Please do not trim the important part:
On 23/03/15 19:31, Luca Barbato wrote:> On 23/03/15 18:38, Nicolas
George wrote:
>> There is something you still do not seem to realize: if your stack is
>> corrupted, abort() is just a crash, anything else is a security
>> issue, including "return foo".
>
> The stack must not be corrupted to begin with, putting an assert after
> the fact is wrong, since it can easily not trigger as well... (or
> trigger the shellcode itself)
> Le tridi 3 germinal, an CCXXIII, Luca Barbato a écrit :
>> Code that can be tested and verified easily actually.
>
> Really? So you mean that for every assert() that you replaced by something
> looking like error handling, you actually did manage to trigger the failure?
I'm quite sure a good deal of them are pointless and I guess if you
assumption about what is a "safe" use of assert() should be revised.
> Writing it explicitly in the code has tons of advantages.
It has none compared to
// this might crash
If you put an assert somewhere near something that is "tricky" and you
leave it always-on, it is just a telltale that that line will cause a
crash. Do not do that.
> Apart from the added safety that I already emphasized, asserts help human
> readers to understand the code.
Once you corrupt the memory you can't do anything safely, including
crashing with a nice glorified abort().
I know you are a strongly opinionated person but you should listen to
the people you are talking to and possibly not derail the discussion in
many rivers with wild claims or dramatic statements.
There is no safe use of assert() if you assume it is anything different
from the debug facility it is.
NO assert should be left in the release builds as no abort() or exist()
should be in a library to begin with.
lu
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
