Re: [PATCH v2 3/3] dtc: Support character literals in bytestrings

[Anton Staaf <robotboy-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]

On Sun, Sep 11, 2011 at 5:48 PM, David Gibson
<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> On Fri, Sep 09, 2011 at 11:37:51AM -0700, Anton Staaf wrote:
>> On Fri, Sep 9, 2011 at 12:25 AM, David Gibson
>> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>> > On Thu, Sep 08, 2011 at 11:30:42PM -0700, Anton Staaf wrote:
> [snip]
>> > I supposed modifying your suggestion, but combining with our existing
>> > convention for "reserved words" we could do:
>> >
>> >        prop = /uint8/ <0xab 0xcd>;
>> >
>> > I don't love it, but it's about the best I've come up with yet.  And
>> > in particular it's probably the variant I'd be least upset to carry
>> > around as legacy if we come up with a better way in future.
>>
>> Yes, I like this better than my suggestions of using !.  I wasn't sure
>> if the /.../ syntax was something that was going to be allowed in
>> property definitions.  One other option working from this could be:
>>
>> property = /size/ 8 <0xab 0xcd>;
>
> I quite like that idea.

OK, I can take a look at writing up a patch to add this.  Unless it
was something anyone else wanted to do.  :)

-Anton

>> It has the advantage of limiting the number of reserved words created.
>>  It could also be:
>>
>> property = /type/ uint8 <0xab 0xcd>;
>
> Not so fond of this one.  The "uint8" would have to be some new
> lexical type - "identifed" probably, which we'd then have to look up.
>
>> Which would allow us to define new types for cell lists without adding
>> new syntax.  I'm not sure if this is too useful though because the
>> only types that I can think of that are not summed up by their size
>> are things like float and double...
>
> Yeah, it's my feeling that the < > symtax should remain for integer
> arrays.  If we need something for other types in future, we should
> define new, distinct syntax for that when the time comes.
>
>> But it does have a nice look to
>> it in my opinion.  And I would assume that if the /type/ <typename>
>> was left off it would default to a uint32_t cell list.  So the
>> additional verbosity of having to indicate it's a different type and
>> what the type is will only be needed in a few instances.
>
> Yes.
>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>