Nested struct (rock) and pass-by-value (hard place) issue.

[jbarrett]

I was planning to do some persistence trickery by doing my drawing onto a RenderTexture, which is a nested struct...

Raylib-FFI/lib/Raylib/FFI.pm

Lines 122 to 132 in 2022665

	package Raylib::FFI::RenderTexture {
	use FFI::Platypus::Record qw( record_layout_1 );
	record_layout_1(
	$ffi,
	uint => 'id',
	opaque => 'texture', # cast to Texture
	opaque => 'depth', # cast to Texture
	);
	}
	$ffi->type( 'record(Raylib::FFI::RenderTexture)' => 'RenderTexture' );
	$ffi->type( 'RenderTexture' => 'RenderTexture2D' );

...that is, its members are not struct pointers, which would be nice and handy, they are stuffed into this struct, so instantiating one (via LoadRenderTexture()) segfaults.

My next thought was to use a FFI::C::Struct, which does support nested structs, but FFI::C objects must be passed into C via FFI::Platypus by pointers - pass-by-value is not supported. Raylib uses pass-by-value.

I don't have any solid ideas to resolve this right now - if I did this would be a pull request. So...

1. Replace the opaques with a type big enough to hold the structs (getting this to align/cast right would be ... "challenging")?
2. Bundle a slew of wrapper functions which do pass-by-reference for structs?
3. Add nested struct support to record or pass-by-value support to FFI::C
4. Look at other tech (Affix? or something called "XS"?)

[jbarrett]

Re 1) I don't think this is at all feasible - consider this total nonsense.

Re 2) I played about with this, there are at least two problems:

• Linking the bundle against the dynamic raylib gets hairy fast, building both static (for linking) and dynamic (for platypus) doesn't seem to be an easy option in Raylib's build system.
  • (update 2026-03-27) There is some address space set up to store context so (on Linux at least) we need to link against the exact same library file as Platypus loads dynamically. Alien::raylib5 currently installs copies of the versioned .so files instead of symlinks so they all resolve as separate library versions and get their own address space. That is, the context set up in Perl/Platypus is not available to code called in the bundle.
• All the pass-by-value stuff is stack-allocated - I think the return pointer would need to be malloced, including allocating nested structs, then memcpyed (or similar) from the stack... again, in a nested way I think?

Re 4) Affix didn't build for me.