"Jeff Latimer" lats@yless4u.com.au wrote:
Coverity Cid:344 highlighted a REVERSE-INULL. This patch removes the redundant null tests as it is clear from the code above that the pointer has already been used to dereference and can't be null.
Yes, 'attr' is used without a NULL check earlier, but that's an actual bug, and that's where the code needs to be fixed.
Dmitry Timoshkov wrote:
"Jeff Latimer" lats@yless4u.com.au wrote:
Coverity Cid:344 highlighted a REVERSE-INULL. This patch removes the redundant null tests as it is clear from the code above that the pointer has already been used to dereference and can't be null.
Yes, 'attr' is used without a NULL check earlier, but that's an actual bug, and that's where the code needs to be fixed.
So in this case my change is ok for the tidy up that it is, it just that there is another problem. Is this in bugzilla?
Jeff
Jeff L wrote:
Dmitry Timoshkov wrote:
Yes, 'attr' is used without a NULL check earlier, but that's an actual bug, and that's where the code needs to be fixed.
So in this case my change is ok for the tidy up that it is, it just that there is another problem. Is this in bugzilla?
Jeff
Looking a bit further it seems that NtCreateMailslotFile is only called from CreateMailslotW. If there is a problem with a NULL then it stems from there. http://source.winehq.org/ident?i=CreateMailslotW
Jeff
"Jeff L" lats@yless4u.com.au wrote:
Looking a bit further it seems that NtCreateMailslotFile is only called from CreateMailslotW. If there is a problem with a NULL then it stems from there. http://source.winehq.org/ident?i=CreateMailslotW
NtCreateMailslotFile is a public API, so probably it should handle the case when attr is NULL. I see the same problem at least in NtCreateNamedPipeFile. In general, handling of OBJECT_ATTRIBUTES in ntdll is not consistent, but fixing it properly most likely a test is needed to see what Windows does in that case.
Dmitry Timoshkov wrote:
NtCreateMailslotFile is a public API, so probably it should handle the case when attr is NULL. I see the same problem at least in NtCreateNamedPipeFile. In general, handling of OBJECT_ATTRIBUTES in ntdll is not consistent, but fixing it properly most likely a test is needed to see what Windows does in that case.
Thanks for that, I will see what I can do about creating a suitable test.
Jeff