[U-Boot] [PATCH 0/4] Fix a few problems with the command parsers

[U-Boot] [PATCH 0/4] Fix a few problems with the command parsers

[Simon Glass]

In a few cases the behaviour of both the hush and built-in parsers seems
incorrect. One such case was exposed by commit 1992dbf which attempted to
execute a simple command using hush and get the correct return value.
Further digging exposed the other problems.


Simon Glass (4):
  Add final result tests for run_command_list()
  Fix itest mask overflow
  Fix hush to give the correct return code for a simple command
  Correct return code from builtin_run_command_list()

 common/cmd_itest.c | 2 +-
 common/hush.c      | 4 +++-
 common/main.c      | 2 +-
 test/command_ut.c  | 5 +++++
 4 files changed, 10 insertions(+), 3 deletions(-)

-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 1/4] Add final result tests for run_command_list()

[Simon Glass]

run_command_list() is supposed to return a return code of 0 for success
and 1 for failure. Add a few simple tests that confirm this. These tests
work both with the built-in parser and hush.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 test/command_ut.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/test/command_ut.c b/test/command_ut.c
index aaa1ee2..b2666bf 100644
--- a/test/command_ut.c
+++ b/test/command_ut.c
@@ -61,6 +61,11 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 		"setenv list ${list}3", strlen("setenv list 1"), 0);
 	assert(!strcmp("1", getenv("list")));
 
+	assert(run_command("false", 0) == 1);
+	assert(run_command("echo", 0) == 0);
+	assert(run_command_list("false", -1, 0) == 1);
+	assert(run_command_list("echo", -1, 0) == 0);
+
 #ifdef CONFIG_SYS_HUSH_PARSER
 	/* Test the 'test' command */
 
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 2/4] Fix itest mask overflow

[Simon Glass]

The mask value used in itest overflows and therefore it can return an
incorrect result for something like 'itest 0 == 1'. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 common/cmd_itest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_itest.c b/common/cmd_itest.c
index ae2527b..76af62b 100644
--- a/common/cmd_itest.c
+++ b/common/cmd_itest.c
@@ -63,7 +63,7 @@ static long evalexp(char *s, int w)
 		l = simple_strtoul(s, NULL, 16);
 	}
 
-	return (l & ((1 << (w * 8)) - 1));
+	return l & ((1UL << (w * 8)) - 1);
 }
 
 static char * evalstr(char *s)
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 3/4] Fix hush to give the correct return code for a simple command

[Simon Glass]

When a simple command like 'false' is provided, hush should return the
result of that command. However, hush only does this if the
FLAG_EXIT_FROM_LOOP flag is provided. Without this flag, hush will
happily execute the empty string command immediate after 'false' and
then return a success code.

This behaviour does not seem very useful, and requiring the flag also
seems wrong, since it means that hush will execute only the first command
in a sequence.

Add a check for empty string and fall out of the loop in that case. That
at least fixes the simple command case. This is a change in behaviour but
it is unlikely that the old behaviour would be considered correct in any
case.

Reported-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
Signed-off-by: Simon Glass <sjg@chromium.org>
---

 common/hush.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/hush.c b/common/hush.c
index 5b43224..7a16795 100644
--- a/common/hush.c
+++ b/common/hush.c
@@ -3218,7 +3218,9 @@ static int parse_stream_outer(struct in_str *inp, int flag)
 			free_pipe_list(ctx.list_head,0);
 		}
 		b_free(&temp);
-	} while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP));   /* loop on syntax errors, return on EOF */
+	/* loop on syntax errors, return on EOF */
+	} while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP) &&
+		(inp->peek != static_peek || b_peek(inp)));
 #ifndef __U_BOOT__
 	return 0;
 #else
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 3/4] Fix hush to give the correct return code for a simple command

[Stefan Herbrechtsmeier]

Am 24.05.2014 05:11, schrieb Simon Glass:

> When a simple command like 'false' is provided, hush should return the
> result of that command. However, hush only does this if the
> FLAG_EXIT_FROM_LOOP flag is provided. Without this flag, hush will
> happily execute the empty string command immediate after 'false' and
> then return a success code.
>
> This behaviour does not seem very useful, and requiring the flag also
> seems wrong, since it means that hush will execute only the first command
> in a sequence.
>
> Add a check for empty string and fall out of the loop in that case. That
> at least fixes the simple command case. This is a change in behaviour but
> it is unlikely that the old behaviour would be considered correct in any
> case.
>
> Reported-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>   common/hush.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/common/hush.c b/common/hush.c
> index 5b43224..7a16795 100644
> --- a/common/hush.c
> +++ b/common/hush.c
> @@ -3218,7 +3218,9 @@ static int parse_stream_outer(struct in_str *inp, int flag)
>   			free_pipe_list(ctx.list_head,0);
>   		}
>   		b_free(&temp);
> -	} while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP));   /* loop on syntax errors, return on EOF */
> +	/* loop on syntax errors, return on EOF */
> +	} while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP) &&
> +		(inp->peek != static_peek || b_peek(inp)));
>   #ifndef __U_BOOT__
>   	return 0;
>   #else
>
Tested-by: Stefan Herbrechtsmeier<stefan@herbrechtsmeier.net>

[U-Boot] [PATCH 4/4] Correct return code from builtin_run_command_list()

[Simon Glass]

The return code is not consistent with builtin_run_command_list(). For the
last command in a sequence, the return code is actually inverted.

Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---

 common/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/main.c b/common/main.c
index 9bee7bd..e2350bd 100644
--- a/common/main.c
+++ b/common/main.c
@@ -1485,7 +1485,7 @@ static int builtin_run_command_list(char *cmd, int flag)
 		++next;
 	}
 	if (rcode == 0 && *line)
-		rcode = (builtin_run_command(line, 0) >= 0);
+		rcode = (builtin_run_command(line, 0) < 0);
 
 	return rcode;
 }
-- 
1.9.1.423.g4596e3a

[U-Boot] [PATCH 0/4] Fix a few problems with the command parsers

[Tom Rini]

On Fri, May 23, 2014 at 09:11:31PM -0600, Simon Glass wrote:

> In a few cases the behaviour of both the hush and built-in parsers seems
> incorrect. One such case was exposed by commit 1992dbf which attempted to
> execute a simple command using hush and get the correct return value.
> Further digging exposed the other problems.

Can you please rebase this on master again?  I imagine it doesn't quite
apply again with the splitting out in main.c series that's applied now,
thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140530/dc8e6dc7/attachment.pgp>

[U-Boot] [PATCH 0/4] Fix a few problems with the command parsers

[Simon Glass]

Hi Tom,

On 30 May 2014 12:59, Tom Rini <trini@ti.com> wrote:
> On Fri, May 23, 2014 at 09:11:31PM -0600, Simon Glass wrote:
>
>> In a few cases the behaviour of both the hush and built-in parsers seems
>> incorrect. One such case was exposed by commit 1992dbf which attempted to
>> execute a simple command using hush and get the correct return value.
>> Further digging exposed the other problems.
>
> Can you please rebase this on master again?  I imagine it doesn't quite
> apply again with the splitting out in main.c series that's applied now,
> thanks!

Yes, I'll take a look now.

Regards,
Simon