On Nov 23, 2015 14:12, "Yann Ylavic" <ylavic....@gmail.com> wrote: > > On Mon, Nov 23, 2015 at 9:00 PM, Marion & Christophe JAILLET > <christophe.jail...@wanadoo.fr> wrote: > > > > Moreover, this kind of patch is a good candidate for backport as it > > introduces many small differences between 2.4 and trunk. > > Without a backport, backporting future patches may become a nightmare. > > Agreed. > > > > > I would find useful to split it into several pieces. > > The first one should apply cleanly to 2.4.x to ease backport. > > Other parts should be splitted in "as many piece as necessary" for potential > > future backport. > > I'll try to merge with svn, and resolve conflicts...
Moreover, I didn't have a chance to review the patch, but all of the instances that 1. map to an RFC protocol string comparison and 2. occur in 2.4 code base *should* be coalesced into one patch. I'm +1 for every such change. The rest of the RFC token comparisons can be added individually for later merging with their associated bug or enhancement backports. I'm strongly -1 for using this function to 'optimize' what is otherwise a non-spec string comparison. There is no excuse for us to defeat good implementations of strcasecmp for the benefit of platforms with shoddy implementations. Jim proposed this as an optimization but I reject that, and wholeheartedly support his suggested use of a predictable ASCII-only folding comparison when following any spec that defines token strings in terms of ASCII alpha chars. We aren't writing a clib but we do have to be mindful of i18n side-effects of the clib we are running within.
