[U-Boot,v3,01/10] Add getenv_ulong() to read an integer from an environment variable

This is not an uncommon operation in U-Boot, so let's put it in a common
function.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Fix commit title from getenv_int() to getenv_ulong()

Changes in v3:
- Move getenv_ulong() function comment into C file
- Add special code for early environment access

 common/cmd_nvedit.c |   25 +++++++++++++++++++++++++
 include/common.h    |    1 +
 2 files changed, 26 insertions(+), 0 deletions(-)

Dear Simon Glass,

In message <1318626284-11161-1-git-send-email-sjg@chromium.org> you wrote:
> This is not an uncommon operation in U-Boot, so let's put it in a common
> function.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
...
> +ulong getenv_ulong(const char *name, int base, ulong default_val)
> +{
> +	char buff[20];
> +	const char *str = NULL;
> +
> +	/*
> +	 * Prior to the import of the environment into the hashtable we
> +	 * should not call getenv()
> +	 */
> +	if (gd->flags & GD_FLG_ENV_READY)
> +		str = getenv(name);
> +	else if (getenv_f(name, buff, sizeof(buff)) > 0)
> +		str = buff;
> +	return str ? simple_strtoul(str, NULL, base) : default_val;
> +}

Sorry, I just changed my mind.

The issue with using getenv() before relocation is that it uses just a
tiny buffer (usually 32 bytes) in the global data structure to store
the result, which is often not sufficient for user provided data (some
boards have hwconfig strings that are _much_ longer than that, and
only the caller knows what to expect).

It's only now that I realize that we are dealing with int / long
values here only, so the length of the expected strings is indeed
limited - actually the buffer you provide here is way smaller that
what getenv() uses.

Can we please switch back to the previous version, but insert a
comment that explains why getenv_f() is not needed in this specific
case?

Thanks, and apologies for causing additional efforts.

Best regards,

Wolfgang Denk

Hi Wolfgang,

On Fri, Oct 14, 2011 at 2:42 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1318626284-11161-1-git-send-email-sjg@chromium.org> you wrote:
>> This is not an uncommon operation in U-Boot, so let's put it in a common
>> function.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
> ...
>> +ulong getenv_ulong(const char *name, int base, ulong default_val)
>> +{
>> +     char buff[20];
>> +     const char *str = NULL;
>> +
>> +     /*
>> +      * Prior to the import of the environment into the hashtable we
>> +      * should not call getenv()
>> +      */
>> +     if (gd->flags & GD_FLG_ENV_READY)
>> +             str = getenv(name);
>> +     else if (getenv_f(name, buff, sizeof(buff)) > 0)
>> +             str = buff;
>> +     return str ? simple_strtoul(str, NULL, base) : default_val;
>> +}
>
> Sorry, I just changed my mind.
>
> The issue with using getenv() before relocation is that it uses just a
> tiny buffer (usually 32 bytes) in the global data structure to store
> the result, which is often not sufficient for user provided data (some
> boards have hwconfig strings that are _much_ longer than that, and
> only the caller knows what to expect).
>
> It's only now that I realize that we are dealing with int / long
> values here only, so the length of the expected strings is indeed
> limited - actually the buffer you provide here is way smaller that
> what getenv() uses.
>
> Can we please switch back to the previous version, but insert a
> comment that explains why getenv_f() is not needed in this specific
> case?

OK I have done that and sent version 4 of that patch.

>
> Thanks, and apologies for causing additional efforts.

No problem.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Status quo. Latin for "the mess we're in."
>