On Thu, Apr 12, 2018 at 05:44:04AM -0500, Kumar Gala wrote: > > > On Apr 11, 2018, at 11:44 PM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Apr 11, 2018 at 09:26:18AM -0500, Kumar Gala wrote: > >> > >>> On Apr 11, 2018, at 12:46 AM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> On Tue, Apr 10, 2018 at 11:42:14AM -0500, Kumar Gala wrote: > >>>> Curious if there is a reason that the alias node name char set is limited to [a-z][0-9] and ‘-‘. > >>>> > >>>> I’m guessing some historic reason, so curious as why that limited > >>>> set. [I really want an emoji in my alias name ;)] > >>> > >>> I'm pretty sure that limitation goes all the way back to IEEE1275, > >>> though I'm not sure of the rationale. Even if the set was widened you > >>> couldn't really have an emoji since an alias - like all node names - > >>> is a bag-o'-bytes, not a Unicode string. > >> > >> Any reason not to update the spec and allow alias names to be > >> treated the same as any property name? > > > > Well, I don't think they should allow anything more than node names, > > rather than property names, although I think the two are identical at > > the moment. The reason is that aliases can appear in paths > > "alias/foo/bar" so we don't want to expand the set of valid path > > characters. > > > > The only printable character I can immediately see as being a definite > > problem is '/'. > > > > Back in the OF days there might have been more restrictions based on > > special characters in the Forth environment, to prevent paths with > > aliases being confused for something else. Not sure. > > Matching the char set for node names seems reasonable to me. > > >> I was joking about the emoji bit. > > > > I thought you probably were :) > > > > I would turn the question around a bit, though: do we have a > > compelling reason to expand the set. Aliases are kind of like > > identifiers and usually languages work best if identifiers have > > characters taken from a fairly small set. > > Mostly we seem to use ‘_’ in a lot of .dts files and figured I’d > raise the discussion on the topic. Since we started warning about > it, wanted to see what direction we might want to take. Yeah, adding _ seems pretty reasonable to me, despite my general misgivings about expanding the set. Expanding allowed things in alias node properties to match property names in general also seems sensible to me. Expanding what's allowed in dtc *labels* on the other hand could cause trouble for the lexer, even though they have a somewhat similar role to aliases. -- 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
Attachment:
signature.asc
Description: PGP signature
