gperf - Patches: patch #9545, Add option to make -k be a list of...
You are not allowed to post comments on this tracker with your current authentication level.
patch #9545: Add option to make -k be a list of key position restrictions instead of a specification
Submitter: | Frank Wojcik <fwojcik> | ||
Submitted: | Sun 21 Jan 2018 05:22:18 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Mon 17 Sep 2018 01:38:03 AM UTC, comment #4: |
Bruno Haible <haible> |
Sun 16 Sep 2018 10:41:07 PM UTC, comment #3: Thanks for the feedback! I will recode the patch to take a new, separate specification.
|
Frank Wojcik <fwojcik> |
Sat 08 Sep 2018 01:15:48 PM UTC, comment #2: I don't much like an option (-A) that influences the way another option (-k) is interpreted. Such a behaviour is hard to explain and easy to misuse. I find it better if all options have a clearly defined meaning on their own.
|
Bruno Haible <haible> |
Sat 10 Feb 2018 01:06:50 AM UTC, comment #1: Adding rev2 of this patch. This fixes 2 bugs in the previous one:
|
Frank Wojcik <fwojcik> |
Sun 21 Jan 2018 05:22:18 AM UTC, original submission:
One of my primary use cases for gperf is to test strings against a membership list consisting of roughly 100-200 strings, all of which can be quite long (>100 characters). gperf can easily create hash functions that access input characters far beyond position 1. While correct and functional, this has caused some cache-related issues, and I sought a way to improve it.
|
Frank Wojcik <fwojcik> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-02-10 | fwojcik | Attached File | - | Added keypos2.diff, #43226 | |
2018-01-21 | fwojcik | Attached File | - | Added gperf-1.diff, #42996 |
Powered by Savane 3.13-758e.
Corresponding source code
"More flexible" with respect to hypothetical use-cases is bloat and a waste of coding effect.
As long as you have one use-case, and other use-case are hard to imagine, it's better to support just that use-case, with options that are as simple as possible to understand.
(Call me short-sighted, if you want. But that's my experience.)