@mflatt Since different architectures implement va_list differently, but still follow a common C interface, would it then be reasonable to add a primitive to internal racket to convert a va_list to a vector? Something like va_list_to_vector() or something like that?

Then we could add that functionality to the FFI library.

(Since at the moment it seems like there is no way to handle a va_list in our ffi)

I don’t think va_list_to_vector() would work well, and probably the C interface would need to be followed more closely with something like va_arg(), and it needs to be in the FFI to work right with types. Also, we’d need a new primitive type for va_list itself.

Sorry, but I couldn’t parse ‘would need to be followed more closely with something like va_arg()‘, could you clarify what you mean by that?

Ah, I think I know what you are saying.

Because we wouldn’t know what the types are, it would be hard to grab the resulting types of data out of the vector.

Adding a (_va-list …) type to our FFI ‘seems’ doable.

It looks like va_list is pointer-sized in practice. So, if you’re trying to call vsnprintf or something like that to format a log message, probably using _pointer will work. Or do you really need access to the individual arguments referenced by the va_list?

Nah, in this case using vsnprintf should work.

I have a format string, and I need expand it.

But that’s about it.

So I’ll give that a shot, thanks.

@mflatt Wouldn’t we actually want vasnprintf?

Since I won’t know how much buffer space I’ll need?

Sounds right

(I don’t know at the variants. I just know to throw in s for “string”, v for va_list, and n at an attempt to be safe.)

Yup

I had to read the man page to get it.

But a is for allocate.

Which means it will eventually need to be freed.

But that one is easy enough to do.

Ideally I would rather use vsnprintf, but there doesn’t seem to be a good api for determining if your buffer was big enough.

And, as far as I can tell, for stuff like that, most c programmers seem to take a ‘good enough’ approach to this.

@mflatt If I have a (_ptr o _string) in my FFI call, with the Racket GC collect the output pointer, or will I have to free it by hand?

Anyway, modulo that possible memory leaked, your suggestion worked. So thanks. :slightly_smiling_face:

(_ptr o _string) allocates GCable memory to receive the _string pointer as well as the string content, so you don’t have to free either. If the called function was returning a char* that needs to be freed, though, then (_ptr o _string) is not a good choice, because you never get to see the returned pointer to free it

Ah, fair. It has an argument for a char*, which fills the pointer with a char.

So you’re saying it would be better to just use a _pointer, copy it into a _string`, and then free the _pointer then?

(As I understand it anyway)

Yes. You can use (_ptr o _pointer), but do the _pointer to _string cast (which will allocate a string) yourself, and then you can free the _pointer value

Cool, thanks.

BTW, I have been meaning to ask, do you have any idea how the Racket7 codebase will effect the FFI?

err…affect*

So far, I think it will mostly work. Finalization will be different, but most finalization patterns will work in both.

Okay, that’s good. Thanks.

(I’ve obviously been making heavy use of it. :slightly_smiling_face: )

@mflatt The racket7 progress is exciting, and your detailed transparency is, as always, much appreciated. :slightly_smiling_face:

ditto what Alexis said. The reason Racket-on-Chez-Scheme doesn’t yet work on Windows is simply because Windows specific functions haven’t been implemented yet?

@mflatt Is there any good way to specify to the Racket FFI that I would like version 6.69.100 and up?)

Or rather, 6.69.100 and up, up to 7.x, and then its incompatible again.

It seems like passing in a whole list of strings to ffi-lib would be massively too long.

I guess I could just do the string processing myself.

hmm…actually, no that won’t work. Because I have to give it an absolute path in that case. :confused:

@leif I don’t know how to do that generally, whether using the Racket FFI or anything else

Ya, I ended up just opening it up, and checking the version after the fact.

I would imagine dlopen has something it does, but that’s more work than I think its worth at the moment.

@abmclin Racket-on-Chez doesn’t yet build on Windows mostly because I haven’t sorted out how a build will work there – not using Unix tools – but also because Windows path parsing is not yet implemented

has anyone here tried sleeping in Mary Gates Hall at the University of Washington? (@alexknauth do you know anyone to ask?)

heh. I think I did once back in the day. probably wasn’t SUPPOSED to. :slightly_smiling_face:

@mflatt Hmm…functions like vasprintf don’t seem to be loaded in Racket’s windows build.

Ah, that specific one is a gnu extension according to SO. oh well. https://stackoverflow.com/questions/40159892/using-asprintf-on-windows