[ntuple] Remove GetView<void> with external address

[hahnjo]

This interface is potentially dangerous since the underlying field is constructed based on the on-disk type name, without being able to verify that the passed pointer is compatible.

---

I left GetView<void>("f") without external address because in principle we can do type checking there (#18316).

[hahnjo]

@amete @Nowakus @Dr15Jones @makortel while discussing #18185, we realized that the current interface of GetView<void>(std::string_view fieldName, void *rawPtr) is potentially dangerous because the underlying field is created based on the on-disk type name without a possibility to check that the passed pointer is compatible. I realize we are quite late here, but how bad would it be if we required passing the type name, effectively mandating #18185?

[Nowakus]

Hi, Once we get the new interface, the one with the typeinfo/typename, we will not need the 'old' one. That's basically what we wanted to have for schema evolution support, as discussed a few weeks ago. Just please keep in mind we also do: ptr = dsc.view->GetField().CreateObject<void>().release(); and view->BindRawPtr( ptr ); and this should probably create the object of "our" type (and bind an object of our type). That's something I just realized - maybe it needs another discussion... Cheers, Marcin

…

On Tue, Apr 8, 2025 at 4:23 PM Jonas Hahnfeld ***@***.***> wrote: @amete <https://github.com/amete> @Nowakus <https://github.com/Nowakus> @Dr15Jones <https://github.com/Dr15Jones> @makortel <https://github.com/makortel> while discussing #18185 <#18185>, we realized that the current interface of GetView<void>(std::string_view fieldName, void *rawPtr) is potentially dangerous because the underlying field is created based on the on-disk type name without a possibility to check that the passed pointer is compatible. I realize we are quite late here, but how bad would it be if we required passing the type name, effectively mandating #18185 <#18185>? — Reply to this email directly, view it on GitHub <#18317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVLCHYSDUIKZJ2UD6UUYCFT2YPLVXAVCNFSM6AAAAAB2WOH3S6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBWGYZDOOBRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***> *hahnjo* left a comment (root-project/root#18317) <#18317 (comment)> @amete <https://github.com/amete> @Nowakus <https://github.com/Nowakus> @Dr15Jones <https://github.com/Dr15Jones> @makortel <https://github.com/makortel> while discussing #18185 <#18185>, we realized that the current interface of GetView<void>(std::string_view fieldName, void *rawPtr) is potentially dangerous because the underlying field is created based on the on-disk type name without a possibility to check that the passed pointer is compatible. I realize we are quite late here, but how bad would it be if we required passing the type name, effectively mandating #18185 <#18185>? — Reply to this email directly, view it on GitHub <#18317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVLCHYSDUIKZJ2UD6UUYCFT2YPLVXAVCNFSM6AAAAAB2WOH3S6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBWGYZDOOBRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[github-actions]

Test Results

    18 files      18 suites   5d 2h 28m 15s ⏱️
 2 719 tests  2 719 ✅ 0 💤 0 ❌
47 470 runs  47 470 ✅ 0 💤 0 ❌

Results for commit 565e4c1.