Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for flexible arrays in bs:struct is missing #41

Open
mwette opened this issue Oct 29, 2020 · 2 comments
Open

support for flexible arrays in bs:struct is missing #41

mwette opened this issue Oct 29, 2020 · 2 comments

Comments

@mwette
Copy link

mwette commented Oct 29, 2020

This is related to issue #39.

C99 allows

struct {
  int narg;
  int args[];
};

I have tried `(args ,(fh:pointer int) 0) but (bytestructure-ref xxx 'args) returns "No such struct field. args"
(where fh:pointer is from issue #39.
Using `(args ,(bs:vector 0 int) does not yield an error, but then not useful for accessing elements of args.
My next step is to update fh:pointer to allow 0 size pointer.

@mwette
Copy link
Author

mwette commented Oct 29, 2020

I'm going back to see if I can make (bs:vector 0 int) work with some changes to the bs:vector implementation.

@TaylanUB
Copy link
Owner

This is very difficult, since the bytevector API doesn't have a thing such as open-ended/variable-length byte vectors; one needs to define a bytevector of a given size before accessing the bytes within the defined region...

Of course, one can always create a new bytevector on-the-fly for every referencing operation for a given index, but that will thrash performance. (This is already a problem with pointer descriptors, which bothers me now that I realized it.)

I have an idea: vector descriptors of size zero could implement a sort of "caching" mechanism: whenever you give them an index, and the cached bytevector is not yet created OR is smaller than the given index, a new bytevector is created that's just big enough to allow using that index.

Disadvantage of that idea: imagine you're iterating through the possible indices into the array. Every index will be one bigger than the last, so the caching is useless; the bytevector is recreated for every iteration anyway. And such iterations are likely to be a common use-case, if not the most common.

Hmm, really not sure what to best do here. It would be rad if Guile had a small and dirty API to directly fetch values from memory addresses, without having to allocate a bytevector object first, but that's unlikely. :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants