Experimental Physics and Industrial Control System
re...
> What I meant to say is that I think that DBF_NO_ACCESS could be removed
> as it isn't useful. I suspect that it exists as a historical echo of
> DBF_NOACCESS in dbAccess.h, which signifies a DB field where the storage
> can't be directly converted to one of the other DBF_* types (eg TIME in
> dbCommon.dbd or VAL in waveformRecord.dbd).
It's useful for autosave. I need to know if a field whose value is to be restored
isn't ready to be written to yet (before record init), because its field type hasn't
been set, or its array space hasn't been allocated.
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
________________________________________
From: [email protected] [[email protected]] on behalf of Michael Davidsaver [[email protected]]
Sent: Wednesday, May 03, 2017 10:13 AM
To: Jeong Han Lee
Cc: [email protected]
Subject: Re: Database Field type in db_access.h
On 05/03/2017 09:27 AM, Jeong Han Lee wrote:
> Hi Michael,
>
>
>
>>>
>>> Please look at db_access.patch, and let me know what you think.
>>>
>>> LAST_TYPE should be DBF_NO_ACCESS instead of DBF_DOUBLE, is it right?
>>
>> The present definition looks correct to me. It did confuse me for a
>> moment until I noticed the '<='
>>
>>> #define VALID_DB_FIELD(x) ((x >= 0) && (x <= LAST_TYPE))
>
>
> I don't follow your explanation. The present definition is following :
>
>
> #define DBF_STRING 0
> #define DBF_INT 1
> #define DBF_SHORT 1
> #define DBF_FLOAT 2
> #define DBF_ENUM 3
> #define DBF_CHAR 4
> #define DBF_LONG 5
> #define DBF_DOUBLE 6
> #define DBF_NO_ACCESS 7
> #define LAST_TYPE DBF_DOUBLE
> #define VALID_DB_FIELD(x) ((x >= 0) && (x <= LAST_TYPE))
> #define INVALID_DB_FIELD(x) ((x < 0) || (x > LAST_TYPE))
>
> If this is correct, what is DBF_NO_ACCESS within that definition? Is
> it in INVALID_DB_FIELD?
My explanation was somewhat truncated as I looked for an example of
where I knew that (IN)VALID_DB_FIELD() should be used, and found that it
wasn't (a bug).
What I meant to say is that I think that DBF_NO_ACCESS could be removed
as it isn't useful. I suspect that it exists as a historical echo of
DBF_NOACCESS in dbAccess.h, which signifies a DB field where the storage
can't be directly converted to one of the other DBF_* types (eg TIME in
dbCommon.dbd or VAL in waveformRecord.dbd).
On the db_access.h side there is at present no real concept of this.
The DBF_* types are used is when mapping to a DBR type, eg.
dbf_type_to_DBR_TIME().
> dbf_type_to_DBR_TIME(DBF_DOUBLE) -> DBR_TIME_DOUBLE
So the fact that DBF_NO_ACCESS doesn't (and imo can't) map to any DBR_*
makes it useless.
Note that DBF_NOACCESS is handled in dbAccess.c with INVALID_DB_REQ(),
eg. in dbGet()
These analogous definitions are found in dbFldTypes.h
>> And similarly in dbf_type_is_valid().
>>
>
> Yes, I saw the similarity in dbf_type_is_valid(). In addition,
> However it is inconsistent if we compare DBR_* with DBF_*. That is the
> first very naive thought I had to create a patch. Then I think, it is
> more than what I think as usual.
>
>
> I found the interesting discussion in tech-talk.
> http://www.aps.anl.gov/epics/tech-talk/2002/msg00137.php
>
>
>> It's actually not apparent to me that 'DBF_NO_ACCESS' can have any valid
>> use. Other than appearing in dbf_text[] it doesn't seem to do anything.
>
>
>
>>
>>
>> And hey, what do you know. RSRV isn't bounds checking the requested DBR
>> type code in event_add_action(), read_notify_action(), or read_action().
>> It uses the dbr_size_n() macro which doesn't bounds check it's first
>> argument, or look for overflow.
>>
>>
>> ...
>>> I didn't commit my change anywhere, so I just generated the
>>> db_access.patch via
>> ...
>>> I just execute the following command (got from Michael)
>>> $ git format-patch -k -1
>>
>> I should have mentioned that this command is only useful after you
>> commit.
>
> I though so, but I prefer not to commit anything to anywhere. :) Once
> I understand the epics base better than, I will use this command to
> create a patch for the community. Thank you again.
>
> Thanks,
> Han
>
>
>
> P.S. Is this right place to discuss this subject? Or do anyone want me
> to move this subject to the normal tech-talk? It is the sort of
> question, which I have now, while I am studying more EPICS itself.
I'm not sure there is a "right" place. I suppose it's a question of
whether you're happy with the response you get ;)
- Replies:
- Re: Database Field type in db_access.h Michael Davidsaver
- Re: Database Field type in db_access.h Michael Davidsaver
- References:
- Database Field type in db_access.h Jeong Han Lee
- Re: Database Field type in db_access.h Michael Davidsaver
- Re: Database Field type in db_access.h Jeong Han Lee
- Re: Database Field type in db_access.h Michael Davidsaver
- Navigate by Date:
- Prev:
Re: Database Field type in db_access.h Michael Davidsaver
- Next:
Re: Database Field type in db_access.h Michael Davidsaver
- 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:
Re: Database Field type in db_access.h Michael Davidsaver
- Next:
Re: Database Field type in db_access.h Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024