bug-gperf
[Top][All Lists]
Advanced

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

Re: [bug-gperf] --global-table bug


From: Bruno Haible
Subject: Re: [bug-gperf] --global-table bug
Date: Thu, 12 Aug 2010 00:04:53 +0200
User-agent: KMail/1.9.9

Hi,

> The bug is that the enum:
> 
> enum
>   {
>     TOTAL_KEYWORDS = 75,
>     MIN_WORD_LENGTH = 19,
>     MAX_WORD_LENGTH = 49,
>     MIN_HASH_VALUE = 22,
>     MAX_HASH_VALUE = 155
>   };
> 
> is made global instead of remaining within the wordlist function.

Yes, --global-table causes these values to become global, because
you want to do something with them. They are meta-information about
the hash function which you wanted to be global.

> This defeats the purpose of specifying distinguished names since
> these five names are not distinguished.

You have multiple ways of avoid name clashes. Use #define and #undef.
Or use different compilation units.

> I suppose it would be a 
> lot of bother to just say, "--prefix=foo" and prefix all global names
> with "foo_"?  e.g.
> 
> enum
>   {
>     FOO_TOTAL_KEYWORDS = 75,
>     FOO_MIN_WORD_LENGTH = 19,
>     FOO_MAX_WORD_LENGTH = 49,
>     FOO_MIN_HASH_VALUE = 22,
>     FOO_MAX_HASH_VALUE = 155
>   };
> 
> (I know, "if I send a patch"... someday when I've got more time than I do.)

I'm not asking for a patch. But if you could describe your use case better,
it may convince me to add a new option for that. What are you attempting to
do that requires --global-table? Why are different compilation units
inadequate? Why are #defines inadequate?

Most of gperf's options are made for the case where it generates an entire
compilation unit. If you #include gperf's generated code from another file,
you need less options from gperf because you can achieve the same effects
with code in the main file.

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]