EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: [Bug 1935037] Re: Invalid charactor in field name
From: Dirk Zimoch via Core-talk <core-talk at aps.anl.gov>
To: core-talk at aps.anl.gov
Date: Fri, 27 Aug 2021 08:04:22 -0000
In order to allow easy structure and array access while having the most flexibility in field names, I suggest to define a *small* set of disallowed chars:
* control codes and space (<= 0x20)
* structure and array access chars: . [ ]
* MAYBE some few other chars like $() because of macros and \ and " because they need to be escaped in JSON.

I would generally allow all other unicode (UTF-8) chars, in particular
accented/modified Latin characters like äöüëßáóúíýàòùǹñøœåš, punktiation
like {}'-+/*;:#% and Asian characters like 文本, ข้อความ. There is no
reason (any more since unicode) to force everyone in the world to the
limited charset used in English. The JSON parser understands unicode
(that is part of the JSON standard).

Also UTF-8 is not particularly difficult to use:
* Nothing changes for English (ASCII)
* A 0x00 byte only appears in \u0000 a the end of a string, thus functions like strlen() and strdup() work perfectly fine getting the right amount of memory bytes.
* A multibyte character is easy to detect (high bit set) and traversing backwards through multibyte characters is easy too, thus truncated strings (-> strncpy) are easy to fix if they cut a character in half at the end.
* Calculating the screen width (number of chars) for adjusting screen output is easy too. (Just don't use strlen() for that).

Instead of blocking the use of UTF-8 with new restrictions, we should
rather aim to support it fully in EPICS DBs (record names, string
values, macro names).

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1935037

Title:
  Invalid charactor in field name

Status in EPICS Base:
  New

Bug description:
  When creating a group in QSRV, the allowed characters are too
  restrictive

  error:
  Error Group not created: Invalid charactor '-' (45) in field name "BI02-TimeRise" must be A-Z, a-z, 0-9, or '_'

  expected behaviour:
  pva structures should allow for a more liberal set of characters that just what is covered by \w regex metacharacter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1935037/+subscriptions


References:
[Bug 1935037] [NEW] Invalid charactor in field name Niko Kivel via Core-talk

Navigate by Date:
Prev: [Bug 1935037] Re: Invalid charactor in field name Timo Korhonen via Core-talk
Next: [Bug 1935037] Re: Invalid charactor in field name Ralph Lange via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: [Bug 1935037] Re: Invalid charactor in field name Timo Korhonen via Core-talk
Next: [Bug 1935037] Re: Invalid charactor in field name Ralph Lange via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 27 Aug 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·