On Sat, 24 Jul 2021, 9:37 am Larry Hastings, <larry@hastings.org> wrote:
On 7/23/21 7:38 AM, Petr Viktorin wrote:
(In both C & C++, the size of an `enum` is implementation-defined. That's unlikely to be a problem in practice, but one more point against enum.)
True, but there's always the old trick of sticking in a value that forces it to be at least 32-bit:
typedef enum { INVALID = 0, RED = 1, BLUE = 2, GREEN = 3,
UNUSED = 1073741824 } color_t;
*/arry*
My current inclination is to define the enum as "_PyLocals_KindValues", and then typedef "PyLocals_Kind" itself as an int. The frame API would then return the former, while the stable query API would return the latter. However, I'll make a full survey of the enums currently in the stable ABI before making a decision, as there may be an existing approach that I like better. I do agree Petr's right to be cautious about this, as compilers can get up to some arcane shenanigans in the presence of formally undefined code: https://queue.acm.org/detail.cfm?id=3468263 The fact that the behaviour in this case is likely to be well-defined at the time of compilation would protect us from the weirder potential outcomes, but it still makes sense for us to define the query API in a way that tells both compilers and humans not to assume that the values returned by the current version of Python are the only values that will ever be returned by all future versions of Python. Cheers, Nick.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3C5ANX5O... Code of Conduct: http://python.org/psf/codeofconduct/