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/3C5ANX5ONLE6OWZ4N24ENDOX2H3R5UC2/
Code of Conduct: http://python.org/psf/codeofconduct/