Re: [PATCH] Need input: Rule IDs

[Tyler Thomas Hart <htyler _at_ pdx _dot_ edu>]

Hey HP,
Thanks for the reply.

On Fri, Dec 14, 2012 at 11:24:58AM +0100, Hans-Peter Deifel wrote:
> On Fr, Dez 14 2012, Tyler Thomas Hart wrote:
> > I need ideas on printing the regex_t stored for regex conditions.
> 
> You can't. Just store the original string somewhere with the rule.

This is what I thought. I am thinking about doing something like this:
typedef struct {
    int condition_type;
    int value_type;
    bool negated;
    union {
        char*       str;
        struct {
            regex_t     exp;
            char*       str;
        } reg;
        int         integer;
    } value;
\} HSCondition;
Note the struct within the union. Thorsten, does your suggestion to always typedef structs apply in this case?

> > We need to decide a way how to handle the rare-rare cases when the index
> > rolls over.
> 
> I'd say, if you're paranoid, use a 64-bit value and you're safe. Even if
> a rule is created every microsecond, that would still last 584554 years
> (5.3 times the time since the beginning of the last glacial period,
> according to wolframalpha ;)

That's a good point, but is it worth the extra memory footprint when most users only have a handful of rules? It might be. Idk. But handling a roll over could be just as simple as telling the user "sorry, you've made too many rules without doing a 'unrule --all' or restarting hlwm. We're reindexing your rules" and then reindexing the queue from 0. Or we could reset the index, enter a 'roll over' state, and actually do error checking to see if an index already exists.

First option sounds unfriendly, second one sounds like a lot of code for a rare, rare case.
For now, yes, I changed it to store indexes as 64 bit val (an unsigned long long).



Also I just noticed I'm dynamically allocating a single (never more, never less) HSRule struct in the _pop function. Preallocating should be fine. Leftovers from debugging. I'll fix that.


Tylo