[GitHub] [tvm] junrushao1994 commented on pull request #8988: [BugFix] Unexpected crash by tricky parameters in TVM's Python API

[GitBox <gi...@apache.org>]

junrushao1994 commented on pull request #8988:
URL: https://github.com/apache/tvm/pull/8988#issuecomment-917350073


   I have to agree that failing, even on adversarially constructed cases by a fuzzer, is actual failing. Thanks for pointing this out 😃🙏
   
   On the other hand, I feel this particular change to the object system might be a bit aggressive, given in TVM nullability by default is allowed by design, and enforcing nullptr checks every time might be contradictory with the assumptions in some pre-historic pieces of the codebase (I'm sure there isn't many though).
   
   Just wanted to share some recent efforts on improving nullability related stuff:
   
   - This RFC introduces the not-nullable macro `TVM_DEFINE_NOTNULLABLE_OBJECT_REF_METHODS`. If an ObjectRef type `T` is marked using this not-nullable macro, then our system will check its nullability to ensure security, unless it is explicitly guarded using `Optional<T>`; Converting `Optional<T>` to `T` incurs nullability checks as well so it's safe;
   - We have several follow-up PRs that migrates many TVM types to not-nullable, so checks are on by default for those types: #5654, #5717, #5748, #5788;
   
   However, the effort was paused because the support is not perfect for composite TVM objects, i.e. TVM objects that contain other TVM objects, and it's less prioritized task given it only helps with adversarially constructed cases, we haven't seen too much progress on this side.
   
   I am happy to chat more if you are interested! More fundamental contribution is warmly welcome ❤️


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org