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 ncoghlan
Recipients eric.snow, ncoghlan, serhiy.storchaka, vstinner
Date 2017-03-23.12:48:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1490273280.72.0.566968293469.issue29881@psf.upfronthosting.co.za>
In-reply-to
Content
Passing var_decl was based on not knowing the answer to two questions:

* do we ever declare non-statics this way? (OTOH, if we do, this could be an opportunity to hide them behind read-only accessor functions)
* do we ever declare more specific types than PyObject * this way? (OTOH, if that's the uncommon case, requiring a cast to the more specific type probably wouldn't hurt)

As far as stack usage goes, all _Py_OnceVar instances should be in the data segment when using the linked list approach, so they shouldn't impact stack usage, and doing so retains the benefit of avoiding dynamic memory allocation just to track the static variable declarations. Since the macro is dereferencing the address of a static variable in the initialiser of another static variable, that shouldn't require any runtime stack space either. OTOH, I haven't actually ever tried compiling a macro like that, so it's entirely possible compilers won't like it.
History
Date User Action Args
2017-03-23 12:48:00ncoghlansetrecipients: + ncoghlan, vstinner, eric.snow, serhiy.storchaka
2017-03-23 12:48:00ncoghlansetmessageid: <1490273280.72.0.566968293469.issue29881@psf.upfronthosting.co.za>
2017-03-23 12:48:00ncoghlanlinkissue29881 messages
2017-03-23 12:48:00ncoghlancreate