ffi pattern matching for pointers in args is broken

[KaruroChori]

For example, right now this signature:

int Fl_Window_x(Fl_Window *);

will generate as AST of its argument:

            {
                "kind": "vardef",
                "type": {
                    "kind": "type",
                    "typeModifiers": [],
                    "name": "Fl_Window",
                    "ptr": 0
                },
                "name": "*"
            }

in place of

            {
                "kind": "vardef",
                "type": {
                    "kind": "type",
                    "typeModifiers": [],
                    "name": "Fl_Window",
                    "ptr": 1
                },
                "name": ""
            }

[saghul]

Ping @lal12 :-)

[lal12]

It indeed doesn't like function prototypes without name. This isn't totally trivially fixable. I've thought for a while about using a PEG grammar based parser instead.

[saghul]

So int Fl_Window_x(Fl_Window *w); should work, right?

[lal12]

So int Fl_Window_x(Fl_Window *w); should work, right?

Yes.

[KaruroChori]

Yes it does, but it cannot count as a workaround if I have to do that hundreds of times :D.
This is the library I am using for reference: https://github.com/MoAlyousef/cfltk

I just got it to work and (almost) automatically translate all bindings for Bun ffi using https://github.com/Morglod/bun-ffi-gen (and a lot of patchwork on its code).
I was just hoping to do the same in txiki but failed for that and few more problems, like preprocessor macros not being expanded.

[lal12]

How about adding a bun ffi compatible wrapper?

[saghul]

How about adding a bun ffi compatible wrapper?

That sounds like a good idea!

[KaruroChori]

As long as the dynamic library is open as RTLD_LAZY and not RTLD_NOW like Bun does :D.
Loading thousands of function signatures and enforcing them all to exist is really not ideal for fast loading time :/
Internally in txiki we are using uv_load, and if I recall correctly for unix systems it wraps dlopen with RTLD_LAZY. So if we keep this behaviour in place it should be fine.

[saghul]

Sounds good!