On 15 September 2014 10:01, Thomas Braibant <[email protected]> wrote: > Thanks for your reply. Your proposal is quite close to what I had in > mind. Yet, I am a bit puzzled about the dereferencing of the pointer > in format_val. Shouldn't we test if it is the null-pointer before > doing that?
Sure: there are different opinions on this, but I agree that a test for null would be reasonable here. > In that case, is testing if p = Ctypes.null the preferred > way to do that? (I spotted that pattern somewhere in memory.ml I > think.) It's better in general to use Ctypes.ptr_compare, since ptr is an abstract type and the values contain extra data besides the raw address. (I think polymorphic equality will do what you expect for the special case of comparing to Ctypes.null, but in general you can have two Ctypes.ptr values referencing the same object but not considered equal by =.) Even better, if your pointers are nullable you might use Ctypes.ptr_opt to construct them, and pattern matching against Some/None to check for null. > Regarding my other use case, what I miss is a way to tag a view (with > the identity coercion both way) with a name, and be able to use that > name to pick the right pretty printer (for flags, and so on). That > would be a tiny bit more convenient than reading the integer value of > (FLAG_BAR | FLAG_FOO) in my log, but I can cope with that. It'd be convenient to have a way to add custom value printers for views, along similar lines to the format_typ optional argument to the view function. I think that would actually solve both your problems neatly: you could have a view with a custom printer for your flags which turned integers into symbolic names, and a view with a custom printer for your pointer-to-struct arguments which printed out the pointed-to values rather than the addresses. Pull requests welcome! (or feel free to raise an issue, if you prefer). _______________________________________________ Ctypes mailing list [email protected] http://lists.ocaml.org/listinfo/ctypes
