tech-misc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Bug in TRE regular expression library



In article <4C45600B.2020004%gmx.de@localhost>, Ralf Junker  
<ralfjunker%gmx.de@localhost> wrote:
>I am looking for someone who maintains the NetBSD TRE code in
>
>  http://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/tre/
>
>Reason is that I believe that I found a bug in TRE.
>
>Unfortunately, the original TRE author is unresponsive to e-mail
>messages. The original TRE mailing lists no longer function, and the
>original TRE repository is no longer available. So it seems that the
>NetBSD port of TRE might be the only maintaind versioin of TRE - at
>least I could find no other.
>
>I am not sure if the problem is relevant to NetBSD, but it might still
>be worth reporting. Below follows my message to Ville Laurikari.
>
>Ralf
>
>------
>
>I am using TRE compiled with both TRE_WCHAR and TRE_MULTIBYTE defined.
>My build passes all tests fine, except for a "special" case (see code
>below).
>
>The special case happens when I set TRE_MB_CUR_MAX = 2 for multi-byte
>character support: Then GET_NEXT_WCHAR() no longer advances str_byte at
>the end of a null-terminated string.
>
>As a result, the example below does match with TRE_MB_CUR_MAX = 2, which
>is *not* correct. With TRE_MB_CUR_MAX = 1 it fails as expected.
>
>A simple fix would be to change tre-match-utils.h line 59 from
>
>  if (w == 0 && len >= 0)
>
>to just
>
>  if (w == 0)
>
>However, I am not sure if this causes any side effects?
>

Which example?

christos



Home | Main Index | Thread Index | Old Index