Drop booth_conf and a few other things

[nrwahl2]

Working on #82.

[nrwahl2]

Fixed a couple of issues, at least one more to fix

[jfriesse]

Using foreach construct is for sure more readable than using C for simply because it adds higher level semantic, and it is nice abstraction well known to anybody who knows higher level languages and probably the reason why widely used C list implementations have some form of foreach abstraction. What if you decide one day there are deployments with too many tickets and find out simple list is too slow and hash table is needed? Then there will be need to change N for cycles instead of having nice abstraction and change only one of them.

[nrwahl2]

Thanks! I always welcome your perspective :)

Personally... I don't mind it at all in languages where foreach (or similar) is a native construct. I find these two macros really annoying, and they increase my cognitive load when looking at the code.

I would like it better if it were a function similar to g_list_foreach, which takes a GList and a function to apply to each member. Of course, that requires functionizing the body of each for loop.

Instead, this is a macro that takes the place of a for loop header and expects a statement after it to act as the body... but that statement isn't an argument and thus isn't part of the macro definition in any way. It feels awkward to me.

One of the most irritating aspects is that the loop counter variable and the data variable both have to be declared outside the scope of the loop. That's another thing that's not an issue with g_list_foreach(), etc.

But honestly, IMO for (int i = 0; i < some_var; i++) { ... } is extremely readable for any C programmer. We're not working with complicated loop headers here. They're as simple as can be.

[jfriesse]

But honestly, IMO for (int i = 0; i < some_var; i++) { ... } is extremely readable for any C programmer. We're not working with complicated loop headers here. They're as simple as can be.

I'm not saying it is not readable, I'm saying foreach is more readable and have foreach abstraction is worth to have, that's it.

[nrwahl2]

I find the existing FOREACH_TICKET/FOREACH_NODE macros significantly less readable than using explicit loop headers.

But in my other branch that has more queued commits, I've added booth__foreach_ticket(), booth__foreach_site(), etc., which apply a function to each item, similar to g_list_foreach as mentioned above. We have similar abstractions in Pacemaker (pe__foreach_bundle_replica(), pe__foreach_const_bundle_replica(), etc.). Hopefully that's something we can be happy with.

I took those changes out of this PR, to make review less daunting.

[nrwahl2]

I've got a lot more commits queued up, but I've reduced this PR to being mostly for dropping booth_conf.

[nrwahl2]

Satisfy Coverity with "Return correct type" commit (plus two other minor ones)

[nrwahl2]

Turns out some of the "unrelated" commits that I had in the first iteration of this PR, were there for a reason :/ I've added more of them again, because Coverity is once again complaining.