Hi,
Charlie Seddon wrote:
cat alfContainerWords.gperf
%{
#include <string.h>
%}
scan
from
to
limit
violation
information
%%
/* Wrapper function for _isContainerWord which gperf will generate */
const char* alfIsContainerWord(const char* name, size_t len)
{
return _isContainerWord(name, len);
}
2.7.2 sees 'scan' as the first keyword, whereas 3.0.1 sees '/* Wrapper
...' a the first keyword.
Indeed, I reproduce this behaviour with this input file.
But already according to the documentation of gperf 2.7.2:
===============================================================================
Input Format to `gperf'
=======================
You can control the input keyfile format by varying certain
command-line arguments, in particular the `-t' option. The input's
appearance is similar to GNU utilities `flex' and `bison' (or UNIX
utilities `lex' and `yacc'). Here's an outline of the general format:
declarations
%%
keywords
%%
functions
_Unlike_ `flex' or `bison', all sections of `gperf''s input are
optional. The following sections describe the input format for each
section.
`struct' Declarations and C Code Inclusion
------------------------------------------
The keyword input file optionally contains a section for including
arbitrary C declarations and definitions, as well as provisions for
providing a user-supplied `struct'. If the `-t' option _is_ enabled,
you _must_ provide a C `struct' as the last component in the
declaration section from the keyfile file. The first field in this
struct must be a `char *' or `const char *' identifier called `name',
although it is possible to modify this field's name with the `-K'
option described below.
Here is a simple example, using months of the year and their
attributes as input:
struct months { char *name; int number; int days; int leap_days; };
%%
january, 1, 31, 31
february, 2, 28, 29
march, 3, 31, 31
april, 4, 30, 30
may, 5, 31, 31
june, 6, 30, 30
july, 7, 31, 31
august, 8, 31, 31
september, 9, 30, 30
october, 10, 31, 31
november, 11, 30, 30
december, 12, 31, 31
Separating the `struct' declaration from the list of keywords and
other fields are a pair of consecutive percent signs, `%%', appearing
left justified in the first column, as in the UNIX utility `lex'.
Using a syntax similar to GNU utilities `flex' and `bison', it is
possible to directly include C source text and comments verbatim into
the generated output file. This is accomplished by enclosing the region
inside left-justified surrounding `%{', `%}' pairs. Here is an input
fragment based on the previous example that illustrates this feature:
%{
#include <assert.h>
/* This section of code is inserted directly into the output. */
int return_month_days (struct months *months, int is_leap_year);
%}
struct months { char *name; int number; int days; int leap_days; };
%%
january, 1, 31, 31
february, 2, 28, 29
march, 3, 31, 31
...
It is possible to omit the declaration section entirely. In this
case the keyfile begins directly with the first keyword line, e.g.:
january, 1, 31, 31
february, 2, 28, 29
march, 3, 31, 31
april, 4, 30, 30
...
===============================================================================
your input file ought to have been interpreted like gperf version 3.0.x does.
Namely, gperf 2.7.2 has interpreted %{ ... %} even in the keywords section,
when the documentation says that it must be part of the declarations section,
and you don't have a declarations section in this file. In other words, the
change was a bug fix.
I received this message when I attempted to use gperf 3.0.1 on a .gperf
file that was working fine on gperf 2.7.1:
address@hidden:...ww/code/ALF % make alfContainerWords.cxx
/usr/bin/gperf -a -o -G -LANSI-C -k 1 -N _isContainerWord \
alfContainerWords.gperf > alfContainerWords.cxx
Empty input keyword is not allowed.
To recognize an empty input keyword, your code should check for
len == 0 before calling the gperf generated lookup function.
make: *** [alfContainerWords.cxx] Error 1
This made me initially think that I could add an inline 'if (len == 0)
return NULL' call in the code to rectify the problem. Attempting to do
so did not solve the problem.
It is true that in theory every error message ought to be prefixed with
"Either the input file is not being interpreted in the way you intended, or ".
And the option --debug does not help either. So the only approach that would
have helped is to simplify the input file until the error disappears.
But that's the same with any compiler. If you get an error that you don't
understand, reduce the input file until the error goes away.
Stepping through gperf's source code ought not to be needed, like you don't
step through gcc's source code either.
Sorry, but I see no concrete step that one could do to make gperf significantly
easier to use.
Bruno