19:13:22Bikecffi does maintain types for pointers, it just ignores them, right? would it be difficult/possible/a good idea to have it type check those?
19:14:44|3b|ACTION didn't think it maintained any types
19:15:37Bikei mean you can specify (:pointer :int) and stuff
19:15:37|3b|at least on sbcl it just returns an (untyped) sbcl pointer value, with no extra cffi type info as far as i know
19:16:11|3b|yeah, you can specify pointer types, but mostly ignored
19:16:35anamorphicLike that (:pointer :int) syntax?
19:24:39phoeI mean, the returned pointers are not typed in any way and a pointer returned from a function that is supposed to return an int pointer can be dereferenced as a float pointer later on and no type errors will happen.
19:25:10phoeI suppose it could, sure - it won't be backwards compatible, obviously, but the type information could be stored somewhere and then checked.
19:25:43LiamHI think the reason for the pointer types is for conversion on dereferencing, especially for structs.
19:28:39phoeLiamH: you can't dereference a pointer in CFFI without providing the type that you want to dereference as.
19:29:02phoeCFFI:MEM-REF requires a foreign type as its second argument.
19:46:34LiamHcffi-libffi, which allows for struct by value call/return, required the type of the struct be specified in order to do the conversion. As a convenience, the ability to specify the type of pointer was added to facilitate similar conversion for call-by-reference, though I don't think that is implemented.
20:04:37karloszis there a quick way in cl to interpret an unsigned 32 as a signed 32?