[TRE-general] Bug report on TRE 0.7.4

[Ville Laurikari]

On Tue, Sep 05, 2006 at 07:15:46PM -0700, Hung-chi Lihn wrote:
> Hi,
>
> When I compile TRE 0.7.4 on Windows platform using a C compiler, I found
> the following coding bugs:

I'm curious, which C compiler are you using?  So far, I've only seen
the Microsoft C/C++ compiler being used to compile TRE on Windows.

> 1.       In tre-match-utils.h, the following statements need to be added
> to the beginning of the file:
>
> #ifdef HAVE_CONFIG_H
>
> #include <config.h>
>
> #endif /* HAVE_CONFIG_H */
>
> It will allow the inline definition to work in a C compiler environment.
> The 2 inline functions probably need a better protection to prevent them
> from being defined multiple times in a C compiler environment if this
> header file is included in multiple files. So far, it only has been
> included in one file.

Every C file already has those three lines before any other
code.  There is no need to include `config.h' from header files.

Did an actual compiler error lead you to this conclusion?  Do you have
a modified version of TRE, are you adding new files, or something like
that?

> 2.       In config.h, it is not clear that TRE_REGEX_T_FIELD needs to be
> defined as value, i.e.,
>
> #define TRE_REGEX_T_FIELD value
>
> After defining this field, the compiler stops complaining
> TRE_REGEX_T_FIELD not defined in a few tre_tnfa related files.

There is a ready-made `config.h' for Windows in `win32/config.h'.  You
should be able to use that even if you're not using the Microsoft
compiler.

The template for `config.h' is `config.h.in'.  It contains this:

/* Define to a field in the regex_t struct where TRE should store a
   pointer to the internal tre_tnfa_t structure */
#undef TRE_REGEX_T_FIELD

Do you have any suggestions on better wording to make it more clear
what you should fill in there?

> 3.       In tre-parse.c, the statements #ifdef tre_isascii and #ifdef
> tre_isblank in struct tre_ctype_map[] should be removed. Otherwise, it
> will not include bothe [:ascii:] and [:blank:] classes if both
> HAVE_ISASCII and HAVE_ISBLANK are not defined
[clip]

Good point, I'll change the code so that you'll get [:ascii:] and
[:blank:] even though you don't have isascii() or isblank().



--
http://www.iki.fi/vl/