[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