Provided that the questions of compatibility are answered positively, I
don't have an objection to allowing utf-8 (aka. 0x7f -> 0xff). However,
I don't like the idea of allowing allowing more characters in the 0x00
-> 0x7e range beyond the current [a-zA-Z0-9_] set.
I gave the example of PVXS to illustrate how I am able to exploit a
restricted character set in a (fairly fast) parser. This is not
something I imagined back when this restriction was added.
--
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 Dirk Zimoch via Core-talk
- Next:
[Bug 1935037] Re: Invalid charactor in field name mdavidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
[Bug 1935037] Re: Invalid charactor in field name Dirk Zimoch via Core-talk
- Next:
[Bug 1935037] Re: Invalid charactor in field name mdavidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|