On 24. 07. 21 1:58, Nick Coghlan wrote:
On Sat, 24 Jul 2021, 9:37 am Larry Hastings, <larry@hastings.org <mailto: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.
Here's a survey: https://bugs.python.org/issue44727#msg398071
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 <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.
If you ask me, I don't think C provides that much type safety to make enum worth it, even for the version-specific API. But I like Larry's "old trick" better than having two different APIs. Thanks for that! It's a new trick for me!