public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/3] env: Tidy up some of the env code
Date: Thu, 30 Jan 2020 21:33:57 +0100	[thread overview]
Message-ID: <20200130203357.32A8024065D@gemini.denx.de> (raw)
In-Reply-To: <0102016eac3ac1a7-8a163dd4-aa1a-4331-a266-e9f461a07db8-000000@eu-west-1.amazonses.com>

Dear James,

In message <0102016eac3ac1a7-8a163dd4-aa1a-4331-a266-e9f461a07db8-000000@eu-west-1.amazonses.com> you wrote:
>
> As I said in my commit log comment, there are two key arguments against 
> this:
> 
> - The fact that the 'data' member of 'struct env_entry' is a 'char *' is 
> really inconvenient because this is a read-only function where most of 
> the callers should be using 'const char *' pointers, and having to cast 
> away the constness isn't good practice and makes the calling code less 
> readable.

So the 'data' member of 'struct env_entry' should be a "const char
*", but that does not mean you have to change the interface of
hsearch_r() ??

> - As you can see from the calling code I've had to tidy up, the callers 
> were very inconsistent about whether they bothered to initialise any 
> fields other than 'key' and 'value', so if you ever wanted to extend the 
> interface to check other parameters you'd have to go around and fix them 
> all up anyway to avoid unpredictable behaviour.

Well, is is good practice to always initialize the complete sruct.
Where this is missing, the code should be fixed.

> Given that only 'key' and 'value' are used at the moment I think my 
> change is preferable because it makes it explicit what is being used and 
> avoids any nasty surprises you might get if you changed hsearch_r() 
> without changing all the callers. If you anticipate wanting to match on 
> other fields, it might be better to define an alternative query 
> structure using 'const char *' pointers for key and value, then extend 
> that, but I would argue that that's something you could do at the point 
> you find it is needed rather than now.

You miss the point that hsearch_r() actually a standard function,
see "man 3 hsearch_r":

HSEARCH(3)                               Linux Programmer's Manual                               HSEARCH(3)

NAME
       hcreate, hdestroy, hsearch, hcreate_r, hdestroy_r, hsearch_r - hash table management

SYNOPSIS
       #include <search.h>

       int hcreate(size_t nel);

       ENTRY *hsearch(ENTRY item, ACTION action);

       void hdestroy(void);

       #define _GNU_SOURCE         /* See feature_test_macros(7) */
       #include <search.h>

       int hcreate_r(size_t nel, struct hsearch_data *htab);

       int hsearch_r(ENTRY item, ACTION action, ENTRY **retval,
                     struct hsearch_data *htab);

       void hdestroy_r(struct hsearch_data *htab);


I object against changing standard interfaces.


I also dislike the seocnd part of the patch.  First, this is
unrelated to the hsearch_r changes, so it should have been a
separate commit anyway.

But renaming _do_env_set() into do_interactive_env_set() makes
absolutely no sense.  It is called in many places from code, which
hav nothing to do with any interactive mode.  Also, I cannot see
what you win by splitting two actions that belong together.


I recommend dropping this patch.

Naked-by: Wolfgang Denk <wd@denx.de>

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Engineering without management is art."               - Jeff Johnson

  parent reply	other threads:[~2020-01-30 20:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191121143240.122610-1-james.byrne@origamienergy.com>
2019-11-21 14:32 ` [U-Boot] [PATCH v2 2/3] env: Tidy up some of the env code James Byrne
2019-11-27  5:52   ` AKASHI Takahiro
2019-11-27  9:39     ` James Byrne
2019-11-27  9:59       ` Simon Goldschmidt
2020-01-30 20:33       ` Wolfgang Denk [this message]
2020-01-30 20:51         ` Simon Goldschmidt
2020-01-31 13:47           ` Wolfgang Denk
2019-11-21 14:32 ` [U-Boot] [PATCH v2 3/3] env: Provide programmatic equivalent to 'setenv -f' James Byrne
2019-12-28  2:26   ` Simon Glass
2020-01-30 20:40   ` [U-Boot] " Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200130203357.32A8024065D@gemini.denx.de \
    --to=wd@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox