Fix memory leak from repeated ProjDataInfo::clone() calls

[NikEfth]

This PR fixes a memory leak detected by AddressSanitizer in ScatterSimulation::set_template_proj_data_info.
The issue was caused by calling arg.clone() multiple times inside dynamic_cast expressions, leading to leaked heap allocations when the cast failed.

The fix:
• Calls clone() exactly once
• Transfers ownership safely using a smart pointer
• Preserves the existing runtime type checks for supported ProjDataInfo types

This change is purely a memory-safety fix and does not alter behaviour or interfaces.

Changes in this pull request

Testing performed

Related issues

Checklist before requesting a review

• I have performed a self-review of my code
• [] I have added docstrings/doxygen in line with the guidance in the developer guide
• [] I have implemented unit tests that cover any new or modified functionality (if applicable)
• The code builds and runs on my machine
• [] documentation/release_XXX.md has been updated with any functionality change (if applicable)

Contribution Notes

Please tick the following:

• The content of this Pull Request (the Contribution) is intentionally submitted for inclusion in STIR (the Work) under the terms and conditions of the Apache-2.0 License.
• I (or my institution) have signed the STIR Contribution License Agreement (not required for small changes).

[NikEfth]

Based on CODACY suggestion I simplified a bit the set_template_proj_data_info() to use the shared_ptr

[KrisThielemans]

I have flagged some minor style issues. In addition, it'd be best to add an overload for backwards compatibility.

void set_template_proj_data_info(const ProjDataInfo&);

which would then have to do the clone and call the other one, e.g.

set_template_proj_data_info(arg.make_shared_clone());

It's possible that you'd have to %ignore the new one in SWIG though.

[KrisThielemans]

delete comment

[KrisThielemans]

and this one

[KrisThielemans]

@NikEfth can we get this one across the line?

[NikEfth]

@NikEfth can we get this one across the line?

All set :)

[KrisThielemans]

final clean-up, please. I guess I'll squash merge this then, if that's alright for you.

[KrisThielemans]

and this one

[NikEfth]

all set

[KrisThielemans]

great. thanks. I forgot to ask to add a line or 2 in release_6.4.htm. I guess in the section bug fixes. sorry

[KrisThielemans]

appveyor builds were failing due to GitHub being unstable (also the webserver).

[NikEfth]

Done

[KrisThielemans]

ah, conflict. can you merge master and resolve? Ideally push with [ci skip]

[NikEfth]

Can you check that everything is fine? I had problems with rebase ...

[KrisThielemans]

That's the main reason why I try to avoid git rebase. Merges have far less trouble. Depending on what happened, we can then squash-merge at the end (although I prefer to do that only for recent/messy PRs that haven't been merged anywhere else, like this one).

I have no obvious way to check if this is still correct due to

• the force-push (ok, maybe the previous commit is still somewhere on github)
• the fact that the last commit has ci skip, so the checks haven't been run.

I have no obvious way to trigger the checks, so I suggest you force-push again after editing the last commit message (git commit --amend), removing the ci skip.