 |
lua-l archive |
|
|
||
|
The callback, as I described above, is the reason for the "cfunction" type. Even though the callback is technically a pointer, the Alien function type doesn't cast out to the containing pointer. If it did, the "cfunction" type would be unnecessary.----- Original Message ----- From: Fabio Mascarenhas Date: 9/3/2008 9:55 PMI wanted to get around to cleaning the 'cfunction' up, and that's why I hadn't submitted a patch yet. As I recall, the situation was thus: A C function required a C callback. The C function was made available via Alien, and the C callback was made available via Alien. However, I couldn't hand the Alien-provided C callback function off as a parameter to the C function.Joshua, could you explain what you use the type "cfunction" for? Maybe I can overload one of the current types (pointer or callback) to do what it does, instead of adding yet another one... and what about the changes to struct (the "I" format and the extra parameter to userdata unpacking)?I can provide the exact example tomorrow for both the callback and the reason (or possibly, non-reason) for the 'I' format parameter.
The 'I' format parameter was to go along along with the 'in' format parameter. According to Roberto's struct documentation:
"in" a signed integer with n bytes (where n must be a power of 2). An absent n means the native size of an int.
"In" like "in" but unsigned. 'I' wasn't supported, but 'i' was.Finally, the extra parameter to the userdata unpacking is to start the unpacking at an offset. In fact, Roberto's struct.unpack(fmt, s, [i])'s final parameter handles the offset. I needed the Alien buffer version to do the same thing, although I would prefer struct.unpack(fmt, buffer, [i], [size]) to my modified struct.unpack(fmt, buffer, size, [i]).
Josh