On Thu, Oct 15, 2015 at 08:05:07AM -0400, Jason Dillaman wrote: > > > I am concerned about passing a void* + length to specify the option > > > value since you really can't protect against the user providing data > > > in the incorrect format. For example, if the backend treated > > > RBD_OPTION_STRIPE_UNIT as a 4byte int, what happens if someone > > > passes a 2- or 8-byte int or a 4-byte char* string? > > > > Then rbd_image_options_set() will fail with EINVAL, because the option > > type (size) is a part of interface. > > > > I do this by analogy to setsockopt(2): > > > > http://pubs.opengroup.org/onlinepubs/009695399/functions/setsockopt.html > > > > Note option type documented for every option there, and it works > > fairly well. > > > > Following a common practice is an additional argument to this > > approach to me. > > Except for the following cases: > > sizeof(char*) == sizeof(uint32_t) (32bit) > sizeof(char*) == sizeof(uint64_t) (64bit) 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); -- Mykola Golub -- 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
