08 Nov, 2019

1 commit

  • 'make tests' on a 32bit ARM system leads to

    In file included from ../common/cli_hush.c:79:
    ../include/malloc.h:364:7: error: conflicting types for ‘memset’
    void* memset(void*, int, size_t);
    ^~~~~~
    In file included from ../include/compiler.h:126,
    from ../include/env.h:12,
    from ../common/cli_hush.c:78:
    ../include/linux/string.h:103:15:
    note: previous declaration of ‘memset’ was here
    extern void * memset(void *,int,__kernel_size_t);
    ^~~~~~
    In file included from ../common/cli_hush.c:79:
    ../include/malloc.h:365:7: error: conflicting types for ‘memcpy’
    void* memcpy(void*, const void*, size_t);
    ^~~~~~
    In file included from ../include/compiler.h:126,
    from ../include/env.h:12,
    from ../common/cli_hush.c:78:
    ../include/linux/string.h:106:15:
    note: previous declaration of ‘memcpy’ was here
    extern void * memcpy(void *,const void *,__kernel_size_t);
    ^~~~~~

    According to the U-Boot coding style guide common.h should be the first
    include.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

12 Aug, 2019

1 commit


07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

16 Aug, 2017

2 commits

  • We are now using an env_ prefix for environment functions. Rename these
    two functions for consistency. Also add function comments in common.h.

    Quite a few places use getenv() in a condition context, provoking a
    warning from checkpatch. These are fixed up in this patch also.

    Suggested-by: Wolfgang Denk
    Signed-off-by: Simon Glass

    Simon Glass
     
  • We are now using an env_ prefix for environment functions. Rename setenv()
    for consistency. Also add function comments in common.h.

    Suggested-by: Wolfgang Denk
    Signed-off-by: Simon Glass

    Simon Glass
     

08 Feb, 2016

2 commits


13 Dec, 2015

1 commit


06 Dec, 2015

2 commits

  • Need to free memory avoid memory leak, when error.

    Signed-off-by: Peng Fan
    Reviewed-by: Simon Glass
    Cc: Simon Glass
    Cc: Tom Rini

    Peng Fan
     
  • Condition "(value == NULL && ++value == NULL)" actully will
    always return false.

    Instead, use condition "(value == NULL || *(value + 1) == 0)" to detect
    such expression "c=". To "c=", *(value + 1) is 0, so directly return -1,
    but not continue.

    Signed-off-by: Peng Fan
    Cc: Rabin Vincent
    Cc: Simon Glass
    Cc: Tom Rini
    Reviewed-by: Simon Glass

    Peng Fan
     

20 Nov, 2015

1 commit


25 Nov, 2014

1 commit

  • 128059b92 ("hush: fix segfault on syntax error") attempted to fix a
    segfault on syntax errors, but it broke Ctrl-C handling, and the
    assumption that it made, that rcode could not be -1, is incorrect.
    Revert this change.

    Reported-by: Stephen Warren
    Reported-by: Przemyslaw Marczak
    Signed-off-by: Rabin Vincent

    Rabin Vincent
     

08 Nov, 2014

3 commits

  • run_command() returns success even if the command had a syntax error;
    correct this behaviour.

    Signed-off-by: Rabin Vincent
    Acked-by: Simon Glass <sjg@chromium.org)

    Rabin Vincent
     
  • Hush segfaults if it sees a syntax error while attempting to parse a
    command:

    $ ./u-boot -c "'"
    ...
    syntax error
    Segmentation fault (core dumped)

    This is due to a NULL pointer dereference of in_str->p in static_peek().
    The problem is that the exit condition for the loop in
    parse_stream_outer() checks for rcode not being -1, but rcode is only
    ever 0 or 1.

    Signed-off-by: Rabin Vincent
    Acked-by: Simon Glass <sjg@chromium.org)

    Rabin Vincent
     
  • Attempting to run:
    - an empty string
    - a string with just spaces

    returns different error codes, 1 for the empty string and 0
    for the string with just spaces. Make both of them return
    0 for consistency.

    Signed-off-by: Rabin Vincent
    Acked-by: Simon Glass <sjg@chromium.org)

    Rabin Vincent
     

27 Oct, 2014

1 commit

  • The run command treats each argument an an environment variable. It gets the
    value of each variable and executes it as a command. If an environment
    variable contains a newline and the hush cli is used, it is supposed to
    execute each line one after the other.

    Normally a newline signals to hush to exit - this is used in normal command
    line entry - after a command is entered we want to return to allow the user
    to enter the next one. But environment variables obviously need to execute
    to completion.

    Add a special case for the execution of environment variables which
    continues when a newline is seen, and add a few tests to check this
    behaviour.

    Note: it's not impossible that this may cause regressions in other areas.
    I can't think of a case but with any change of behaviour with limited test
    coverage there is always a risk. From what I can tell this behaviour has
    been around since at least U-Boot 2011.03, although this pre-dates sandbox
    and I have not tested it on real hardware.

    Reported-by: Wolfgang Denk
    Signed-off-by: Simon Glass

    Simon Glass
     

12 Jun, 2014

1 commit


06 Jun, 2014

1 commit

  • 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
    Signed-off-by: Simon Glass

    Simon Glass
     

30 May, 2014

5 commits