[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: alien library - proposed changes
- From: Cosmin Apreutesei <cosmin.apreutesei@...>
- Date: Tue, 28 Jul 2009 17:21:12 +0300
As I am writing some wrappers with alien, I have compiled a small list
of changes that would make alien work better with complex and/or bad
APIs. I'm planning to implement them myself as time allows, but I'd
thought I'd post them here first to avoid any duplicate work :) I'd
appreciate any comment on why any of these is a bad idea.
1) buf:topointer(offset) -> light_userdata
motivation: neither alien.to<type>(), buf:tostring(s), nor
struct.unpack(layout,buffer,size) don't have an offset parameter; the
returned userdata could be wrapped up with buffer(), or dereferenced
2) buf:tostring([size, [offset]])
motivation: allow easy extraction of a small structure out of a large
buffer for processing with struct.unpack().
3) alien.to<type>(buffer, [offset])
motivation: allow easy dereferencing a pointer inside a buffer
(multi-dimensional arrays etc.)
4) struct.size('p') -> sizeof(void*)
motivation: for when sizeof(void*) is different than sizeof(int), and
for better expression of intent.
5) struct.pack('p', light_userdata or buffer)
motivation: allow packing structures with pointer members; keeping the
buffer from being garbage-collected is left to the programmer.
6) struct.unpack('p', string, offset) -> light_userdata
motivation: allow unpacking structures with pointer members; the
resulted luserdata could then be wraped up with buffer or dereferenced
7) struct.unpack(layout, string or buffer, [offset, [size]])
motivation: generalize unpack to work with buffers and strings
transparently given an offset and size.
8) struct.unpack_offsets(layout, string or buffer, [offset, [size]])
-> offset1, offset2, ...
motivation: directly access a member without unpacking the whole structure.
*) update documentation, unittesting.