gnunet-developers
[Top][All Lists]
Advanced

[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.
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]