From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 11 Sep 2009 11:39:19 -0500
Subject: [U-Boot] [PATCH] cmd_fdt.c: fix parse of byte streams
	and	strings
In-Reply-To: <4AAA7B41.3020505@ge.com>
References: <m3ws46fpfo.fsf@bitsko.slc.ut.us> <4AA9987F.60608@gmail.com>
	<20090911161645.GA13783@b07421-ec1.am.freescale.net>
	<4AAA7B41.3020505@ge.com>
Message-ID: <4AAA7D37.3000303@freescale.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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