> > But we don't need them to match between different platforms, no? Is > linking 64bit code with 32bit possible (supported)? > > Also, for this particular (char*) case, length would actually be the > length of the string, not the pointer length. From my example: > > const char* journal_object_pool = "journal"; > r = rbd_image_options_set(opts, RBD_OPTION_JOURNAL_OBJECT_POOL, > journal_object_pool, strlen(journal_object_pool) + > 1); > My original example was a string of length 4 vs a 4-byte int, but you said you were thinking of sizeof(type) instead. I think this style of interface is great if you need to pass any arbitrary data along, but will we ever expect to pass along anything besides a string or an (u)int(32/64)? On the flip-side, what will the C++ interface look like? An equivalent API would imply passing a boost::any. While certainly future-proof, something about that doesn't sit right with me as an API. I think I would lean more towards something like xyz_set(const std::string&), xyz_set(uint64_t), et al. I've been witness to too many type-casting issues in the past (in fact just hit one last night within CephContext), which makes me lean more towards having the compiler be able to enforce type-correctness. -- Jason -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
