On 24. 07. 21 1:58, Nick Coghlan wrote:
On Sat, 24 Jul 2021, 9:37 am Larry Hastings, <la...@hastings.org
<mailto:la...@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!
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/JIBBPKHA5URUBKF43XWMUANP5ESQB4JM/
Code of Conduct: http://python.org/psf/codeofconduct/
