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

Complete libmarshall testing on array types #54

Open
spk121 opened this issue Sep 3, 2019 · 2 comments
Open

Complete libmarshall testing on array types #54

spk121 opened this issue Sep 3, 2019 · 2 comments

Comments

@spk121
Copy link
Owner

spk121 commented Sep 3, 2019

There are a few test cases left to cover for GArray, GPtrArray, GByteArray, and GBytes in libmarshall

@spk121
Copy link
Owner Author

spk121 commented Sep 15, 2019

Previously, there was the LATER_FREE mechanism used to free temporary variables created during argument marshalling, and this worked because those temp variables were created using a malloc analog, and the GPtrArray that held objects to be freed called free on all the pointers when it was destroyed. But when adding these array types, there are now temp variables that need to call specific destructors, such as GPtrArray. So the LATER_FREE mechanism will need to be improved. Each pointer needs to be paired with a closure of a free function.

@spk121
Copy link
Owner Author

spk121 commented Sep 15, 2019

GBytes could just be unpacked as a bytevector, but, it has the added wrinkle that its contents are supposed to be read only. Since there is no such thing as a read-only bytevector on the scheme side, there are a couple of options.

  1. Always make a new copy of the contents and return that as a bytevector
  2. Keep it as an object, and use methods like g_bytes_unref_to_array unpack its contents
  3. Put read-only bytevectors in core Guile

I think I'll roll with option number 2 for now.

LordYuuma added a commit that referenced this issue Feb 6, 2020
LordYuuma added a commit that referenced this issue Feb 14, 2020
These tests were wrongfully omitted in the transition to SRFI tests (#63),
specifically in b85fa1c.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant