[PATCH 2/5] env: Fix env_get() when returning empty string using env_get_f()

Marek Behún kabel at kernel.org
Sun Oct 31 16:27:07 CET 2021


On Sun, 31 Oct 2021 07:07:47 -0600
Simon Glass <sjg at chromium.org> wrote:

> Hi,
> 
> On Fri, 29 Oct 2021 at 03:03, Pali Rohár <pali at kernel.org> wrote:
> >
> > On Thursday 28 October 2021 21:17:38 Simon Glass wrote:  
> > > Hi Marek,
> > >
> > > On Wed, 27 Oct 2021 at 21:28, Marek Behún <kabel at kernel.org> wrote:  
> > > >
> > > > From: Marek Behún <marek.behun at nic.cz>
> > > >
> > > > The env_get_f() function returns -1 on failure. Returning 0 means that
> > > > the variable exists, and is empty string.
> > > >
> > > > Signed-off-by: Marek Behún <marek.behun at nic.cz>
> > > > ---
> > > >  env/common.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)  
> > >
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > >
> > > But it isn't normally possible to set an env var to an empty string.
> > > How does this happen?  
> >
> > IIRC you can set variable to empty string via e.g.:
> >
> > setenv abc ''  
> 
> Yes that works and I now see you are all right. In fact the command
> handling for 'env set' does not use env_set().
> 
> It seems a bit inconsistent to me. Since a deleted variable is
> considered empty, do we need to support empty vars?

Depends on what you mean by "support". I think that if the user
does

  setenv xyz ""

it shouldn't be an error. Whether it deletes the variable or not is
something different (although I would make it so that the variable is
not deleted...).

But env_get_f("xyz") shouldn't return -1 in this case, as that indicates
an error.

Marek


More information about the U-Boot mailing list