Re: [PATCH 04/18] Offer a function to demote fsck errors to warnings
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 23, 2014, 16:30 UTC
- Message-ID
- <alpine.DEB.1.00.1412231723480.21312@s15462909.onlinehome-server.info>
- In-Reply-To
- <xmqqr3vq49w5.fsf@gitster.dls.corp.google.com>
Hi Junio,
On Tue, 23 Dec 2014, Junio C Hamano wrote:
Show 10 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > However, if we had to change the lookup such that it uses an array > > always, we would have to introduce a function to initialize the > > struct, always, in particular we would have to find a place to call > > that initialization function in, say, builtin/fsck.c (actually, in > > every code path that calls into the fsck machinery). > > You would need to call a function to "initialize" the table if you > support customization by reading the configuration files anyway.
Yes, this is the config machinery. But I need employ that only if I want to let the caller customize the severity levels. However, the fsck machinery is also called from places where such a customization is not offered. They would now need to be changed, too.
Show 39 quoted lines
> Also I suspect that you can tell the compiler to initialize the
> array in place with default values, perhaps like this?
>
> -- >8 --
> #include <stdio.h>
>
> /* sorted by the default severity (lowest impact first) */
> #define EVENT_LIST(F) \
> F(EVENT_A), \
> F(EVENT_B), \
> F(EVENT_C), \
> F(EVENT_D)
>
> #define ID_(event) ID_ ## event
> enum event_id {
> EVENT_LIST(ID_)
> };
>
>
> enum severity_level {
> severity_info, severity_warn, severity_error
> };
>
> /* below this one are INFO */
> #define FIRST_WARN_EVENT_ID ID_EVENT_B
> /* below this one are WARN */
> #define FIRST_ERROR_EVENT_ID ID_EVENT_C
>
> #define STRING_(s) #s
> #define DESC_(event) \
> { \
> ID_ ## event, \
> STRING_(event), \
> (ID_ ## event < FIRST_WARN_EVENT_ID \
> ? severity_info \
> : ID_ ## event < FIRST_ERROR_EVENT_ID \
> ? severity_warn \
> : severity_error) \
> }This is exactly the ugly, ugly preprocessor construct I thought you would meet with contempt. I mean, compared to this, my FUNC() hack is outright pretty ;-)
And *still*, this is *just* a global table with defaults. I would *still* need to copy-on-write when the first customization of the severity level takes place because I cannot allow the global defaults to be modified by one caller (that would defeat the whole purpose of having per-caller settings bundled in the fsck_options struct).
You see, I still would need to have a lazy initialization, the complexity in that part would not be reduced at all.
So I am afraid that this approach really adds complexity rather than replacing it with something simpler than my current code.
Ciao, Dscho