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

[Scott Wood]

Jerry Van Baren wrote:
> 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?
> 
> That *is* a string, 

No, a string list is not a string.  It is a set of strings that have been 
concatenated, but which retain their individual null terminators (as in the 
compatible property).

> 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? ====
> --------------------------------------------------------------

I'm not thrilled with it...  I'd think the code could be made to handle the [, 
], <, or > being in the same parameter as one of the numbers.

-Scott