Why use size and alignment reporters?

[slburson]

I've just noticed that Claw receives the size and alignment of each type from libresect. Why doesn't it just record that information directly in the deficlass/defistruct form rather than generating reporters to obtain it at runtime? Is there some scenario in which it would get different values at runtime?

[borodust]

The reason is portability, basically. Between compilers, OS, specific compilation flags. libclang isn't overly precise tool. The best authoritative information is what you can get from the compiled binary.

[slburson]

Here's how this came up. I noticed that sb-alien:with-alien, and cffi:with-foreign-pointer which wraps it, normally allocate on the stack. I would like to use stack allocation in many cases, but these interfaces have no provision for specifying alignment; apparently, only 8-byte alignment (on a 64-bit machine) is guaranteed. LibTorch has one type, complex<double>, that uses 16-byte alignment. (I called all of the alignment-reporters to find this.) While I do not need to stack-allocate one of those today, I would like my code not to break if it happens. That means writing a macro like with-intricate-alloc that does alignment itself, by requesting extra space and adjusting the foreign pointer as needed. And to do that, it would be convenient, though of course not necessary, to know the alignment value at macroexpansion time; I can generate a better expansion in the vast majority of cases in which 8-byte alignment is sufficient.

Calling the alignment reporter at macroexpansion time would require that the foreign library had been loaded, which seems infelicitous. So I wondered whether that information was available from libclang, and saw that it was, and is even being captured. It surprises me that you say it could be wrong. Did you actually see a case of this, or did you just not feel confident about it?

BTW, the last line of intricate-alloc looks wrong; size and alignment are swapped.

[slburson]

The best authoritative information is what you can get from the compiled binary.

But this isn't guaranteed to be accurate either, because it's coming from the generated adapter, not the original library. You have to be just as careful to configure that compilation correctly as you would configuring libclang, if we used the libclang numbers.

[borodust]

Absolutely. The recommended way is to statically link the C shim. That's one of the reasons all of my wrappers are linked to the specific sources of the upstream library.

[borodust]

And if one decides to use dynamic linking for the C shim, it's on them to make sure the linking is correct (C++ dynamic linking is ass).

[slburson]

It's not just about the linking, though. Really, what you should do is to add the adapter to the library source tree, including the CMake files or whatever it uses, and build it all together.

[borodust]

Yes, correct. I usually add an original library as a subproject to CMake of a shim. This way both static and dynamic linking both work as expected, because this guarantees binary compat.