[U-Boot] [PATCH] cmd_fdt.c: fix parse of byte streams and strings

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Scott Wood wrote:
> On Thu, Sep 10, 2009 at 08:23:27PM -0400, Jerry Van Baren wrote:
>>    fdt set /ethernet at f00 interrupts "this is a string"
>> can now handle multiple strings (words) by concatenating them with 
>> spaces (quoted strings still work the same as before because of hush's 
>> argument parsing)
>>    fdt set /ethernet at f00 interrupts this is a string
> 
> How do you set a string list, then?
> 
> -Scott

Hi Scott,

That *is* a string, the two examples are equivalent.  The proposed 
parser change glues all the parameters together with a single space. 
The string parsing doesn't worry me because it is 100% backward 
compatible with the original parsing, e.g. these two commands will 
result in the same string being stored in the FDT:
   fdt set /ethernet at f00 interrupts "this is a string"
(one parameter with explicit spaces)
   fdt set /ethernet at f00 interrupts this is a string
(five parameters with implicit spaces).

If you want two spaces between words, you would have to use the 
explicitly quoted version:
   fdt set /ethernet at f00 interrupts "this  is  a  string"

Strings are backwards compatible because the hush parser strips the 
quotes so all that that part of Ken's patch does is to extend it to 
paste together multiple arguments rather than limiting it to exactly one 
argument.  The following also produces the original string:
   fdt set /ethernet at f00 interrupts "this is" "a string"

I'm more concerned with the [] form because that really is a syntax 
change.  The original syntax with a single quoted argument will no 
longer be parsed if I understand the change (I need to apply the patch 
and confirm this):
Old:
    fdt set /ethernet at f00 interrupts "[33 2 34 2 36 2]"
becomes
    fdt set /ethernet at f00 interrupts [ 33 2 34 2 36 2 ]
Note that the *must* be a space between "[" and "33" and between "2" and 
"]" because the "[" and "]" now have to be separate arguments.  This is 
what Andy did with "<" and ">" with no public outcry, so it is probably OK.

--------------------------------------------------------------
==== Does anybody have a problem with this syntax change? ====
--------------------------------------------------------------

If humans are typing the commands it shouldn't be a big deal.  If 
someone has those commands embedded in a script, their script will break 
and they will have to update it per the new syntax.

FWIIW, Andy's syntax is much cleaner than my original (must quote) 
syntax (other than the need for spaces between the "[" "]" "<" ">" 
symbols and the numbers, but I can accept that).

Best regards,
gvb