On Thursday, March 8, 2012 at 10:54 AM, Noah Watkins wrote: > > On Mar 8, 2012, at 10:48 AM, Greg Farnum wrote: > > > On Thursday, March 8, 2012 at 9:30 AM, Noah Watkins wrote: > > > > > > On Mar 7, 2012, at 1:40 PM, Greg Farnum wrote: > > > > > > > CephMount::conf_get requires a buf_size. But we freely adjust that if we need more space, so is there any point to it? I can't see callers really having a better idea of size than we do. > > > Good point. I can't think of a reason to publicly expose the buffer length param in CephMount to users, but CephProxy is a private interface. On a related a related note: > > > > > > int ceph_conf_get(struct ceph_mount_info *cmount, const char *option, char *buf, size_t len); > > > > > > shouldn't the 'buf' parameter be char ** if libcephfs is going to be doing a re-alloc, or is there some voodoo behind the scenes? > > libcephfs doesn't do a re-alloc there; I was talking about the Java stuff when I said it freely adjusts. :) > > > > The documentation seems to indicate that it does do a malloc. Maybe it is just out of date? > > /* Returns a configuration value as a string. > * If len is positive, that is the maximum number of bytes we'll write into the > * buffer. If len == -1, we'll call malloc() and set *buf. > * Returns 0 on success, error code otherwise. Returns ENAMETOOLONG if the > * buffer is too short. */ Ah. Two things from that: 1) "If len == -1". Which it isn't, here. 2) There is no voodoo, that just isn't going to work. Either it was created incorrectly in reference to md_config_t::get_val, or else code got moved around without updating that documentation. :/ Options including char ** (as you said), char *& (ewww), or…not doing that? Anybody have thoughts on the right solution? -Greg -- 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
