I expect the functional-style casts for `unsigned long long` and maybe
`long long` to fail to compile on non-Windows systems.
Existing code in bgl.cc#py_module_dict_add_int64 calls
#PyLong_FromLongLong and passes it an `int64_t` argument directly, so
I'm assuming it is safe to do this and also to pass a `uint64_t`
directly into #PyLong_FromUnsignedLongLong.
Now that reading an input sequence in foreach_set for a PROP_RAW_CHAR
property requires all values to fit within the minimum and maximum of
`uint8_t`, the buffer formats compatible with PROP_RAW_CHAR should be
updated to match.
Signed integer raw types are still considered compatible with unsigned
buffers, but maybe that should change too, since, for example, `128`
cannot be stored in a `int8_t`, but can in a "B" (`unsigned char`)
buffer, which would be considered compatible if the property had the
`PROP_UNSIGNED` flag.
This is a potentially breaking change because these parsing functions
perform their own overflow checks, whereas before, `OverflowError` would
only have been raised when the input integer was too large to represent
as signed/unsigned `long`/`long long`, even when the raw property type
could only store much smaller values.
This change is probably OK however, because integer properties have a
well-defined minimum and maximum value, which should always fit in the
property's raw type, enum properties have a fixed number of values they
can take depending on the enum's items, and bool properties should
usually only be `0` and `1`.
Note, however, that bool properties with raw array access do not use the
#PROP_RAW_BOOLEAN type because DNA does not have a bool type, so the raw
property type will usually match one of the other single-byte types
instead. Most bool properties use a bitmask, which disables raw array
access, so this is expected to be an uncommon case.
For a user-facing release notes, the change could be written like:
`bpy_prop_collection.foreach_set()` is more restrictive with integer,
enum and bool properties, and will raise a `TypeError` when an input
value cannot be stored by the property's internal type.
If it's safe to do so, it may be worth replacing use of
#PROP_RAW_CHAR/`char`, #PROP_RAW_SHORT/`short` and #PROP_RAW_INT/`int`
with their fixed-width counterparts, so that all raw access is done with
fixed-width types.
RNA raw types were missing for the `int8_t`, `uchar` (`uint8_t`),
`ushort` (`uint16_t`), `int64_t` and `uint64_t` DNA types types.
For #115413 specifically, 27a5da4dc3 replaced the `char` fields used by
the `handle_left_type` and `handle_right_type` enum properties with
`uint8_t` fields. Without an RNA raw type being set for properties using
`uint8_t` fields, `rna_access.cc#RNA_property_raw_type()` would fall
back to assuming the raw type was `PROP_RAW_INT` which would then fail
due to #92621.
This patch adds the missing RNA raw types for all DNA types.
The `int64_t` and `uint64_t` types can currently only be used by bool
properties (see `IS_DNATYPE_BOOLEAN_COMPAT` and the other macros in
RNA_define.hh), which will means that `PROP_RAW_INT64` and
`PROP_RAW_UINT64` will be unused because bool properties use
`PROP_RAW_BOOLEAN`.
Properties with one of the new unsigned raw types have a difference in
behaviour to their signed counterparts in foreach_getset, in that
attempting to set a negative number raises a Python OverflowError (which
is caught and then re-raised as TypeError).
Thomas Barlow