Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Wed, 3 May 2017 11:13:53 -0400

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 ;)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System