| 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Database Field type in db_access.h |
| From: | Jeong Han Lee <[email protected]> |
| To: | Michael Davidsaver <[email protected]>, [email protected] |
| Date: | Wed, 3 May 2017 15:27:11 +0200 |
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?
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 -1I 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, HanP.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.