You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue includes the issue pointed to by #8144, but was never actually fixed upstream due to developer inactivity.
As such, I'm riving their issue, and expanding on it - I found another place where it was assumed the user would never use naked pointers in the object API.
Additionally, defining just a field with a naked_ptr attribute on a circular table type can also result in erronous code:
table A{
field1: B (cpp_ptr_type:"naked");
field2: B (cpp_ptr_type:"naked");
}
table B {
blah: uint;
}
root_type B;
inline void A::UnPackTo(AT*_o, const ::flatbuffers::resolver_function_t *_resolver) const {
(void)_o;
(void)_resolver;
{ auto _e = field1(); if (_e) { if(_o->field1) { _e->UnPackTo(_o->field1.get(), _resolver); } else { _o->field1 = (_e->UnPack(_resolver)); } } else if (_o->field1) { _o->field1.reset(); } } // Notice that .get() and .reset() are called
{ auto _e = field2(); if (_e) { if(_o->field2) { _e->UnPackTo(_o->field2.get(), _resolver); } else { _o->field2 = (_e->UnPack(_resolver)); } } else if (_o->field2) { _o->field2.reset(); } } // Notice that .get() and .reset() are called
}
In order to address this, I'm issuing a new PR that I will carry all the way through. The PR will include the fix from the included issue, as well as the fix for the second example.
The text was updated successfully, but these errors were encountered:
This issue includes the issue pointed to by #8144, but was never actually fixed upstream due to developer inactivity.
As such, I'm riving their issue, and expanding on it - I found another place where it was assumed the user would never use naked pointers in the object API.
Here was their original example:
Given this simplified schema:
The erronous code is produced here:
Additionally, defining just a field with a naked_ptr attribute on a circular table type can also result in erronous code:
In order to address this, I'm issuing a new PR that I will carry all the way through. The PR will include the fix from the included issue, as well as the fix for the second example.
The text was updated successfully, but these errors were encountered: