Having trouble using gperf:Empty input keyword is not allowed

Question

command_options.gperf:

%{
#include "command_options.h"
typedef struct CommandOptionCode CommandOptionCode;
%}
struct CommandOption
  {
  const char *Option;
  int OptionCode;
  };
%%
+helpverbose, CommandOptionCode::HELPVERBOSE
+password, CommandOptionCode::PASSWORD
+nocopyright, CommandOptionCode::NOCOPYRIGHT
+nolog, CommandOptionCode::NOLOG
+_64bit, CommandOptionCode::_64BIT

command_options.h:

#ifndef __COMMANDOPTIONS_H
#define __COMMANDOPTIONS_H
struct CommandOptionCode 
  {
  enum 
    {
    HELPVERBOSE = 1,
    PASSWORD = 2,
    NOCOPYRIGHT = 3,
    NOLOG = 4,
    _64BIT = 5
    };
  };
#endif

When I run:

gperf  -L C++ -t --output-file=perfecthash.hpp command_options.gperf

Only to get :

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.

Version: GNU gperf 3.0.1 Why?

Answer 1

I discovered that gperf 2.7 did not care if there was a '%%' delimiter between the first section and the keywords. 3.0.1 strictly enforces this. So, in my case I had modify:

%{
#include <string.h>
%}

scan

to be

%{
#include <string.h>
%}
%%

scan

Your case is different, I belive, in that the manual states that the first field of the struct must be called 'name':

"This first field must be called `name', although it is possible to modify its name with the `-K' option (or, equivalently, the `%define slot-name' declaration) described below."

-charlie

Answer 2

I discovered that gperf does not like empty lines in the keyword section. It treats a blank line as a null string I guess, since it is not a comment, and complains about it being 'empty' and having len=0. Since I have a habit of always ending a file with an empty line (there are some assemblers and compilers that baulk at not having it) it was always going to be a problem!

Answer 3

In addition to the blank line issue mentioned by Richard, gperf also does not like spaces preceding certain tokens. (I had cut and pasted a simple gperf sample that looked for "rude" words in a user's input. The name of the sample was rude-1.gperf. The sample had some indentation that triggered this same error.)