WIP: Fix #115413: Missing PropertyRNA rawtype set for some DNA types #115506

Closed
Thomas Barlow wants to merge 1 commits from Mysteryem/blender:fix_missing_raw_type_set_pr into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

makesrna.cc#rna_set_raw_property was missing support for the int8_t,
uchar (uint8_t) and ushort (uint16_t) DNA 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 int8_t, uchar and ushort DNA types to
makesrna.cc#rna_set_raw_property.

The int64_t and uint64_t DNA types remain absent from
makesrna.cc#rna_set_raw_property because these types have no
corresponding RawPropertyType and these types can only be used by bool
properties (see IS_DNATYPE_BOOLEAN_COMPAT and the other macros in
RNA_define.hh), and bool properties use PROP_RAW_BOOLEAN.

`makesrna.cc#rna_set_raw_property` was missing support for the `int8_t`, `uchar` (`uint8_t`) and `ushort` (`uint16_t`) DNA 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 `int8_t`, `uchar` and `ushort` DNA types to `makesrna.cc#rna_set_raw_property`. The `int64_t` and `uint64_t` DNA types remain absent from `makesrna.cc#rna_set_raw_property` because these types have no corresponding `RawPropertyType` and these types can only be used by bool properties (see `IS_DNATYPE_BOOLEAN_COMPAT` and the other macros in `RNA_define.hh`), and bool properties use `PROP_RAW_BOOLEAN`.
Thomas Barlow added 1 commit 2023-11-28 06:43:28 +01:00
makesrna.cc#rna_set_raw_property was missing support for the `int8_t`,
`uchar` (`uint8_t`) and `ushort` (`uint16_t`) DNA 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 `int8_t`, `uchar` and `ushort` DNA types to
makesrna.cc#rna_set_raw_property.

The `int64_t` and `uint64_t` DNA types remain absent from
makesrna.cc#rna_set_raw_property because these types have no
corresponding RawPropertyType and these types can only be used by bool
properties (see `IS_DNATYPE_BOOLEAN_COMPAT` and the other macros in
RNA_define.hh), and bool properties use `PROP_RAW_BOOLEAN`.

I have doubts about unsigned data types having the same PROP_RAW_ mapping as signed types. By reading RAW_GET/RAW_SET code, these feel totally incompatible with handling of unsigned values currently, since they interpret the pointers as signed ones? So the expected unsigned range cannot be properly covered.

Would like to summon @brecht and/or @ideasman42 here too?


Not directly related to this patch:

  • Am kinda wondering why we should not add the other missing types as well (all the [u]int_xxt, uint, etc) while we are at it?
  • Also think we should add explicit full support of (u)int_64t to RNA?
I have doubts about unsigned data types having the same `PROP_RAW_` mapping as signed types. By reading `RAW_GET`/`RAW_SET` code, these feel totally incompatible with handling of unsigned values currently, since they interpret the pointers as signed ones? So the expected unsigned range cannot be properly covered. Would like to summon @brecht and/or @ideasman42 here too? --------------------------- Not directly related to this patch: * Am kinda wondering why we should not add the other missing types as well (all the `[u]int_xxt`, `uint`, etc) while we are at it? * Also think we should add explicit full support of `(u)int_64t` to RNA?
Author
Member

I have doubts about unsigned data types having the same PROP_RAW_ mapping as signed types. By reading RAW_GET/RAW_SET code, these feel totally incompatible with handling of unsigned values currently, since they interpret the pointers as signed ones? So the expected unsigned range cannot be properly covered.


Not directly related to this patch:

  • Am kinda wondering why we should not add the other missing types as well (all the [u]int_xxt, uint, etc) while we are at it?
  • Also think we should add explicit full support of (u)int_64t to RNA?

This is pretty much what I did first, but I decided to keep the patch simpler and it wasn't
clear to me how foreach_getset should deal with unsigned types because the signed/unsigned of the raw type is not exposed to the Python API, which can make it more difficult to write performant foreach_get/set code, and there's the issue of OverflowError being raised when setting unsigned types to negative values: 06abf39164 edit: Now submitted as !115761 so it can be commented on/reviewed as necessary.

> I have doubts about unsigned data types having the same `PROP_RAW_` mapping as signed types. By reading `RAW_GET`/`RAW_SET` code, these feel totally incompatible with handling of unsigned values currently, since they interpret the pointers as signed ones? So the expected unsigned range cannot be properly covered. > > --------------------------- > > Not directly related to this patch: > > * Am kinda wondering why we should not add the other missing types as well (all the `[u]int_xxt`, `uint`, etc) while we are at it? > * Also think we should add explicit full support of `(u)int_64t` to RNA? This is pretty much what I did first, but I decided to keep the patch simpler and it wasn't clear to me how `foreach_getset` should deal with unsigned types because the signed/unsigned of the raw type is not exposed to the Python API, which can make it more difficult to write performant foreach_get/set code, and there's the issue of OverflowError being raised when setting unsigned types to negative values: https://projects.blender.org/Mysteryem/blender/commit/06abf39164e589e4f019a135dd315853e1f4c9c2 edit: Now submitted as !115761 so it can be commented on/reviewed as necessary.

I would expect any differences between signed/unsigned to be taken care of by min/max range of the property? Did you check if it does?

As long as setting those values clamps to the range, it should be ok to add the unsigned types.

I would expect any differences between signed/unsigned to be taken care of by min/max range of the property? Did you check if it does? As long as setting those values clamps to the range, it should be ok to add the unsigned types.
Author
Member

There's definitely issues with the data types with this patch. The example that I've tested is accessing an int8_t PROP_INT property set to -1 with foreach_get, which returns 255 because the Python ints are constructed from an array that is considered to be char (PROP_RAW_CHAR) type which is unsigned in Blender. The Python ints being created in bpy_rna.cc#foreach_getset() with item = PyLong_FromLong(long(((char *)array)[i]));.

I expect there's similar issues using unsigned types with the existing signed raw types too.

There's definitely issues with the data types with this patch. The example that I've tested is accessing an `int8_t` `PROP_INT` property set to `-1` with `foreach_get`, which returns `255` because the Python ints are constructed from an array that is considered to be `char` (`PROP_RAW_CHAR`) type which is unsigned in Blender. The Python ints being created in `bpy_rna.cc#foreach_getset()` with `item = PyLong_FromLong(long(((char *)array)[i]));`. I expect there's similar issues using unsigned types with the existing signed raw types too.
Thomas Barlow changed title from Fix #115413: Missing PropertyRNA rawtype set for some DNA types to WIP: Fix #115413: Missing PropertyRNA rawtype set for some DNA types 2023-12-13 05:10:53 +01:00
Author
Member

Closing in favour of !115761.

Closing in favour of !115761.
Thomas Barlow closed this pull request 2023-12-20 18:51:44 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#115506
No description provided.