Hi Alfio,
On Mar 8, 2021, at 1:14 AM, Alfio Rizzo via Tech-talk < tech-talk at aps.anl.gov> wrote:
At ESS we have the convention to have in a particular position of the record name,
the '#' character for "internal" record, i.e. a record which is used for instance for intermediate calculations,
In practice this internal record should not be used outside the IOC,
i.e. no channel finder, no archiving , no alarm, no autosave, and so on.
We use as well the '-' and ':' characters to separate some record name part, e.g.
"Normal" Record Name
Sys-Sub:Dis-Dev-Idx:Prop
"Internal" Record Name
Sys-Sub:Dis-Dev-Idx:#Prop
'#', ':', '-' as well as '_' are 'legal' or 'illegal' characters ?
Can we use them without the possible risk to have EPICS crashing in any future release ?
The colon, dash and underscore characters :-_ have always been legal characters in record names. I have
seen the hash character # (also known as octothorpe, pound or number sign) used often enough that I think that will be safe – we use it here at APS, which is a good indication that any attempt to make it illegal would get
vetoed by me. As Michael said, the main point of the changes recently was to allow us to reserve syntax that wouldn’t conflict with existing names, and your use above is unlikely to have that problem.
- Andrew
-----Original Message-----
From: Tech-talk < tech-talk-bounces at aps.anl.gov> On Behalf Of Michael Davidsaver via Tech-talk
Sent: Saturday, June 13, 2020 5:08 PM
To: Hu, Yong < yhu at bnl.gov>
Cc: EPICS Tech-Talk < tech-talk at aps.anl.gov>
Subject: Re: weird record names?
On 6/10/20 9:13 AM, Michael Davidsaver wrote:
On 6/9/20 6:33 PM, Hu, Yong wrote:
Michael,
When you say "restrictions", does that mean a newer version of EPICS IOC will fail to load a .db file in which a record name contains a "weird" character?
Eventually, yes. That is what I'm considering.
cf. for a concrete proposal. https://github.com/epics-base/epics-base/pull/78
If the IOC fails to load .db because it does not follow the new rules/restrictions, facilities that have already used "weird" characters will suffer badly when they upgrade EPICS base to a newer version.
I recognize and want to avoid this.
Any new restriction would begin as a warning, and likely remain so for
a number of years.
This would mainly serve as an early indication of names which would
cause problems in other contexts. Record names which would be
impossible in link to (like "a b" below, or "123"), or which would
never parse as channel names (like "x.y").
3.15.0.1 introduced a warning for record names containing " \"'.$".
These might now begin to be enforced. And include "\t" for good
measure.
Yong
On 6/8/20, 5:09 PM, "Tech-talk on behalf of Michael Davidsaver via Tech-talk" <tech-talk-bounces at aps.anl.gov on behalf of
tech-talk at aps.anl.gov> wrote:
I'm looking to collect examples of epics record names in the wild.
This is an early step towards (maybe) adding restrictions on what
characters a record name can contain, and in what positions.
eg. restricting possible first and last characters.
In particular I'm looking for examples including characters
beyond the usual alphanumeric separated by ':' or '-'.
And in what positions they may (or may not) appear.
An example from the NSLS2 naming convention (for which I am have
some responsibility).
TST{evm:1D-DlyGen:31}Evt:Trig2-SP
Which is notable for containing "{" and "}" in the middle.
As background. At present, records can be created with almost
any characters in a name.
record(ai, "a b") {}
record(ai, "x.y") {}
record(ai, "x\"") {}
However, record names including '.' can't be addressed and aren't
very useful. Further, names including spaces can't be targeted
by links.
On the subject of links. Dirk was surprised to find that
the syntax for link parsing treats "[0]" as a record name,
but "[0,1]" as a constant array.
https://urldefense.com/v3/__https://bugs.launchpad.net/epics-base/*bu
g/1882520__;Kw!!P4SdNyxKAPE!TwNJ4RpksYZmN8YbfgjiN7Y3igc4486VOLcj-_1L1
KUqPcMdbvxVXH_bSrI3$
Rather than carving out another exception, I'd like to look at
coding a general rule.
--
Complexity comes for free, simplicity you have to work for.
|