Allow extern types without any members

[lundmark]

So I want to have this:

"MyExternalType" : { "extern" : true }

as a type because I want to do:

{ "name": "test", "type": "MyExternalType*", "default" : null }

as a member of my struct. Right now there's no real way I can do this without actually declaring the exact struct even though I'm only using it as a pointer.

[wc-duck]

I guess this can be done but I wondering what your usecase is. If you can't load it from data and can't save it to data, does it have to be part of said data? And how would you handle pack of such a struct if the pointer was set?

[lundmark]

The usercase is a declared struct (which doesn't even exist) only to have a strict way of passing C-barrier between dll/executable... so for example:

class MyCoolType { ... }

typedef ApiMyCoolType;

void my_binder_func(ApiMyCoolType my_internal_data_which_I_need) { MyCoolType stuff = (MyCoolType*)(my_internal_data_which_I_need)

Which is just a fancier way of using void*.

So the pointer is not allowed to be packed. If it is set, the packing should assert/crash etc.

[wc-duck]

Why not pass API and data separately?

[lundmark]

I'm not 100% sure what you mean, but the API and the data is passed separately. The API is one struct with function pointers. The data that you operate on is hidden by a type that is predeclared but never defined. I have no intention of rewriting the whole c-api and I think that it's a feature that reasonably should be supported in the datalibrary.

I mean, just adding the type intptr_t to dl would suffice I guess?

[wc-duck]

I just can't understand why you need to store that pointer in a struct that, I guess, you load from disk? Are you returning dl-structs from your lib and then when you "get back" into your code you need to find the API to use that strict with? In that case, IMHO, it would be nicer to work with your type as

struct handle { API, data }

[lundmark]

Well, to be honest I've moved away from generating code / data into generating dl-data. This includes that some of the structs contains both data that is serialized from disk which also contains runtime data. So in this situation the struct contains for example a 64-bit hashed path and the loaded instance of that. So it's a reference which is a type that's handled specifically. To be more precise:

struct a { uint64_t path; (some other data here); Level *pointer_initialized_to_zero_but_used_in_runtime; }

struct b { a _a; (some other data here) };

struct c { b _b; (some other data here) };

c is serialized.

So my only alternative is that I instead either serialize a pointer-sized type like uint64_t (which would be much better with intptr_t), OR that I use like an index which is just default-serialized as 0 and then indexed into a list. The latest is probably the most "pretty" one but I'd rather have the pure pointer there as that decreases indirections and honestly is much less work to handle.

[wc-duck]

intptr_t is actually not that easy to handle as convert 64bit -> 32bit can't always be performed. If it should be added I will add it as another flag, not extern but maybe "opaque" or something as they would behave differently? I'm still not a fan but I might add it anyways.

[lundmark]

Ah that's right... Well, if it's trying to do that (like, say that the intptr_t when converting from 64 to 32 bit is more than INTPTR32_MAX or whatever that definition is) then it should probably error-out?

[wc-duck]

Have this been solved in another way or is this still a request?

[lundmark]

This is still a request. Currently we just use intptr_t basically.

On Mon, Oct 15, 2018 at 1:33 PM Fredrik Kihlander notifications@github.com wrote:

Have this been solved in another way or is this still a request?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wc-duck/datalibrary/issues/71#issuecomment-429815945, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXOMnOxSDZKpwLwVrSyAoLagD_yEta3ks5ulHKEgaJpZM4Rac3E .

[wc-duck]

If I fix "no_check" from #99 it would be easy to do this with just a dummy-member in the external type?

[lundmark]

Hmm yes I think so, as long as no sizeof or other things on the type would be done. I would assume that DL would give errors if I tried to create an instance of that type though.

[wc-duck]

It will not handle that, it will be considered a type as any else so it up to the calling code to ensure it is null. Regardless of how I look at opaque types I can't motivate my self to think that it is a good idea so that will not be added. But as said, with no-check and a dummy-member you would get most of what you are after and I hope that it is enough.

[wc-duck]

I'll consider this fixed now