Hi Michael,
I worked on the following epics-base :
$git rev-parse HEAD
8677c845283873895f39d81feca36cb24699e5ee
$ git log -1
commit 8677c845283873895f39d81feca36cb24699e5ee
Author: Michael Davidsaver <[email protected]>
Date: Thu Apr 27 15:30:35 2017 -0400
libCom: dbmfMalloc cantProeed() on failure
most calling code doesn't check for NULL.
Thanks,
Han
> Which revision should this patch be applied against? That is, branch
> name and/or git/bzr revision hash.
>
> Michael
>
>
> On 04/27/2017 07:38 PM, Jeong Han Lee wrote:
>> Hi,
>>
>> I did modify the records, which I mentioned in tech-talks as below:
>> http://www.aps.anl.gov/epics/tech-talk/2017/msg00690.php
>>
>> Main focus are the following three items
>> 1. recGblResetAlarms returns unsigned short / epicsUInt16
>> 2. recGblCheckDeadband uses "unsigned (int) / epicsUInt32
>> 3. db_post_events uses "unsigned int / epicsUInt32
>>
>> So, I decided to minimize any changes on the monitor functions.
>>
>> Please let me know what you think.
>>
>> Thanks,
>> Han
>>
>>
>
- Replies:
- Re: Patch file for Records which use consistent epics data types Michael Davidsaver
- References:
- Patch file for Records which use consistent epics data types Jeong Han Lee
- Re: Patch file for Records which use consistent epics data types Michael Davidsaver
- Navigate by Date:
- Prev:
Re: Patch file for Records which use consistent epics data types Michael Davidsaver
- Next:
Re: Patch file for Records which use consistent epics data types 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: Patch file for Records which use consistent epics data types Michael Davidsaver
- Next:
Re: Patch file for Records which use consistent epics data types 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
|