> > [...] > That svn_utf_cstring_to_utf8(&utf8_opt_arg, opt_arg, pool) at the top of > the loop guaranees that utf8_opt_arg is in the pool. In all the case I > pointed out, that string was copied into the same pool again. Before you > change, that actually happened immediately after the conversion. > > You're right.
> > > Previously, they were duplicated by svn_utf_cstring_to_utf8(), which > allocates the result in a pool even if no actual conversion has been > performed. > > > But that's exactly what's happening after your change, too, you just moved > the conversion to the top of the loop, which is fine. > > In the following changes I removed this conversion from the top of the loop, but instead it is performed in the beginning of the function through svn_cmdline__get_utf8_argv(). > > For example, check out this block of code, existed in the trunk before: > > case opt_encoding: > opt_state.encoding = apr_pstrdup(pool, opt_arg); > break; > > > > You changed that opt_state.encoding to be in UTF-8 (a change that, by the > way, I'm not sure about. That value is a parameter for the xlate functions, > which may require the original native-encoded name). > > Yup. I think I clarified this in the log message. I dug down into xlate a little bit and it seems like they will be fine with utf8 parameters. And since our api works with utf8 strings, why would this be an issue? > Basically I want to avoid or minimise changing behaviour in utf8-isation. > > Also this may be cool to introduce an iterpool into the argument handling > loop. In this case it's mandatory to copy them to the right one. > > > Well clearly the utf8-converted option arg has to be allocated in the > result pool in the first place. Why would you do the conversion into an > iterpool, then copy the result to the result pool? That doesn't make sense. > -- Timofei Zhakov
