[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two small questions about some components
From: |
Christian Grothoff |
Subject: |
Re: Two small questions about some components |
Date: |
Tue, 20 Apr 2021 23:55:29 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
Hi Alessio,
Both of these sound reasonable, but please make sure to update the
documentation of gnunet-config when you do this!
-Christian
On 4/20/21 11:31 PM, Alessio Vanni wrote:
> Hello,
>
> I was investigating something in the codebase and found two things I'd
> like to ask clarifications for. They are small and there is no need to
> send two different mails, hence the subject of this mail.
>
> 1. I was looking at common_logging.c and found this:
>
> static enum GNUNET_ErrorType
> get_type (const char *log)
> {
> if (NULL == log)
> return GNUNET_ERROR_TYPE_UNSPECIFIED;
> if (0 == strcasecmp (log, _ ("DEBUG")))
> return GNUNET_ERROR_TYPE_DEBUG;
>
> /* ...Other lines omitted for brevity... */
>
> return GNUNET_ERROR_TYPE_INVALID;
> }
>
> which is used during the logging component's initialization.
>
> The question is: is there a reason why the argument is compared with the
> gettext-ized version of each "type"?
> From a "user interface" point of view, one would expect for the
> following call to have the same effect regardless of the current locale:
>
> GNUNET_log_setup("component", "WARNING", NULL);
>
> but according to the above function, unless I'm missing something
> obvious, if the current locale contains a translation for "WARNING",
> then the actual log level will be different than the desired one.
>
> ***
>
> 2. The `gnunet-config' tool in its current implementation, always writes
> the full configuration to file after changing something and writes only
> the modified parts when using the `-w' switch.
>
> I think the behaviour should be swapped, as writing the whole
> configuration will cause obsolete values to persist and potentially hard
> to diagnose problems to appear, e.g. version X requires a certain value
> to work around an issue, found after release and which version X+1
> fixes, so the config change is not required, but users with modified
> configs will still load the "wrong" value.
>
> The patch to change the flag meaning is a one-liner, but first I'd like
> to ask if maybe there was already some discussion about this behaviour,
> or maybe even something about changing gnunet-config, so that I don't
> submit a useless patch.
>
> Thanks,
> A.V.
>