[issue35842] A potential bug about use of uninitialised variable

rongxin added the comment: Josh Rosenberg, thanks for your useful comments. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue35842] A potential bug about use of uninitialised variable

Josh Rosenberg added the comment: One additional note, just in case you're wondering. slice explicitly does not set Py_TPFLAGS_BASETYPE (in either Py2 or Py3), so you can't make a subclass of slice with NULLable fields by accident (you'll get a TypeError the moment you try to define it). The

[issue35842] A potential bug about use of uninitialised variable

Josh Rosenberg added the comment: Yes, the 2.7 version of _PyEval_SliceIndex would bypass the NULL pointer dereference, so *if* you could make a slice with a NULL stop value, you could trigger a read from uninitialized stack memory, rather than dying due to a NULL pointer dereference. But j

[issue35842] A potential bug about use of uninitialised variable

Change by rongxin : -- resolution: not a bug -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue35842] A potential bug about use of uninitialised variable

rongxin added the comment: I think this bug is valid at least in Python 2.7, as I mentioned the implementation of _PyEval_SliceIndex is different from the one in Python 3.8. The condition " if (v != NULL && v != Py_None) " will bypass the NULL pointer dereference. Would you please check this

[issue35842] A potential bug about use of uninitialised variable

rongxin added the comment: Hi, Josh Rosenberg. As you mentioned PySlice_New (which is ultimately responsible for all slice construction) explicitly replaces any argument of NULL with Py_None, I am not sure whether this is always true r->stop cannot be NULL. I detected this bug using the code

[issue35842] A potential bug about use of uninitialised variable

Josh Rosenberg added the comment: Your analysis would be (almost) correct if a slice object could have a stop value of NULL. It's wrong in that the error would be a NULL deference, not a silent use of an uninitialized value, but it would be a bug. In your scenario where v == NULL, it would p

[issue35842] A potential bug about use of uninitialised variable

rongxin added the comment: BTW, if this bug is true, there is a similar code snippet in the same file. mmapmodule.c: 845 static int 846 mmap_ass_subscript(mmap_object *self, PyObject *item, PyObject *value) 847 { ... 888else if (PySlice_Check(item)) { 889Py_ssize_t start, stop, step

[issue35842] A potential bug about use of uninitialised variable

New submission from rongxin : In the source file mmapmodule.c, the function mmap_subscript contains a potential bug about the use of uninitialised variable. mmapmodule.c: 764 static PyObject * 765 mmap_subscript(mmap_object *self, PyObject *item) 766 { ... else if (PySlice_Check(item)) {