On Sat, Apr 20, 2013 at 2:27 PM, Stefan Sperling <s...@apache.org> wrote: > On Tue, Apr 16, 2013 at 02:15:17PM +0400, Ivan Zhakov wrote: >> Hi, >> >> I got following failures when running Debug build with VC 2010: >> FAIL: log_tests.py 40: test 'svn log -g --search' >> FAIL: log_tests.py 39: 'svn log --search' >> >> They fail because of assertion in VC runtime: >> [[[ >> W: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c(68) : Assertion >> failed: (unsigned)(c + 1) <= 256 >> ]]] > > Seems like a bogus check to me. Is there a notion of debug vs. release > builds in Visual Studio, and if so, does this happen in release mode > builds? > > tolower() is supposed to return the byte unchanged in case it cannot > be converted to a lower-case representation. I would expect that > to happen in your case. > > See http://pubs.opengroup.org/onlinepubs/9699919799/functions/tolower.html > It doesn't say "fail if the value overflows". It doesn't fails, it just asserts because caller violated API restrictions. See Bert's reply.
> >> This happens because apr_fnmatch does not handle UTF8 character and >> pass UTF lead char to tolower() call. There is already XXX comment in >> apr\strings\apr_fnmatch.c:121 > > Yes, apr_fnmatch() doesn't support multi-byte characters yet. > And it never has. But the fnmatch implementation was changed > in APR-1.4.5, so it is possible that this problem didn't trigger > with the old implementation. > >> Easy solution could be use apr_fnmatch without APR_FNM_CASE_BLIND and >> make svn --search case-sensitive. Alternative solution is convert >> search pattern and search string to lower case before passing to >> apr_fnmatch. > > How is lower-casing a multi-byte UTF-8 character going to help? > Won't the lower-case equivalent still be a multibyte character > and trigger the overflow check in Visual Studio? > Because in this case we can call apr_fnmatch without APR_FNM_CASE_BLIND, avoid tolower calls and get case-insensitive match. >> And third option is to fix apr_fnmatch(). > > I'd very much like to do that, actually. Just have to find time. I think the problem that svn log --search is case-insensitive only for ASCII (latin) chars, while characters in other locales handled in case-sensitive way. This could confuse non-English users. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
