This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients benjamin.peterson, gregory.p.smith, pitrou, siddhesh, skrah, steve.dower, vstinner
Date 2018-10-23.13:20:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1540300811.02.0.788709270274.issue33015@psf.upfronthosting.co.za>
In-reply-to
Content
Unfortunately, this isn't really a safe cast, as we're going from void to non-void return value.

On x86 with current calling conventions, this is okay, since the return value is in a register that does not change or require cleanup by the caller. However, I wouldn't want to assume that all future calling conventions on other architectures would also permit this - returning a pointer value on the stack or in some way that requires cleanup is entirely possible, and is the sort of problem that would likely only be detectable by this warning or very careful memory measurements (or possibly a very confusing crash due to invalid stack modifications). 

It's also possible that returning an invalid pointer could cause a compiler to one day invoke its undefined behavior clause. Even though *we* don't use the return value, it still gets returned somewhere.

I'm not thrilled about the memory allocation here either, but there isn't really much of an option in my opinion.
History
Date User Action Args
2018-10-23 13:20:11steve.dowersetrecipients: + steve.dower, gregory.p.smith, pitrou, vstinner, benjamin.peterson, skrah, siddhesh
2018-10-23 13:20:11steve.dowersetmessageid: <1540300811.02.0.788709270274.issue33015@psf.upfronthosting.co.za>
2018-10-23 13:20:11steve.dowerlinkissue33015 messages
2018-10-23 13:20:10steve.dowercreate