[issue31337] Small opportunity for NULL dereference in compile.c

Barry A. Warsaw added the comment: Alright, I'm going to close this bug in favor of bpo-31338 -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker __

[issue31337] Small opportunity for NULL dereference in compile.c

Barry A. Warsaw added the comment: See bpo-31338 for adopting the abort() idiom. -- ___ Python tracker ___ ___ Python-bugs-list mailin

[issue31337] Small opportunity for NULL dereference in compile.c

Barry A. Warsaw added the comment: On Sep 4, 2017, at 10:18, Serhiy Storchaka wrote: > Serhiy Storchaka added the comment: > > Could you please also look at other asserts? I have counted 48 occurrences of > assert(0), 11 assert(0 && "message") and 2 assert(!"message"). If fix one > occurrence

[issue31337] Small opportunity for NULL dereference in compile.c

Stefan Krah added the comment: I'm very much in favor of using abort() /* NOT REACHED */ in such cases. The only drawback is that in the case of libraries, sometimes distribution package lint tools complain. -- nosy: +skrah ___ Python tracker

[issue31337] Small opportunity for NULL dereference in compile.c

Serhiy Storchaka added the comment: Could you please also look at other asserts? I have counted 48 occurrences of assert(0), 11 assert(0 && "message") and 2 assert(!"message"). If fix one occurrence, why not fix all others? -- ___ Python tracker

[issue31337] Small opportunity for NULL dereference in compile.c

Barry A. Warsaw added the comment: I'll preface that it's not a major issue that I feel *has* to be fixed, but given that assert *can* be compiled away, does it make sense to use abort() instead? E.g. 1 file changed, 2 insertions(+), 2 deletions(-) Python/compile.c | 4 ++-- modified Python

[issue31337] Small opportunity for NULL dereference in compile.c

Changes by Barry A. Warsaw : -- pull_requests: +3325 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue31337] Small opportunity for NULL dereference in compile.c

Serhiy Storchaka added the comment: The default case is added just for silencing compiler warning. It is never executed. There are a number of places in the core that look like assert(0); return NULL; /* or whatever */ This is a dead code, but compilers complain without it. How do you

[issue31337] Small opportunity for NULL dereference in compile.c

Barry A. Warsaw added the comment: As it's barely worth fixing, it's not worth backporting. -- ___ Python tracker ___ ___ Python-bugs-

[issue31337] Small opportunity for NULL dereference in compile.c

New submission from Barry A. Warsaw: There is a very minor opportunity for NULL dereference in compile.c. compiler_subdict() does not check the return value of get_const_value(), which could be NULL. This was found by Kirit Sankar Gupta. This is not a security issue in practice, since compil