b7f8f172273c3580c57be9b24c6cc6cb16573377
Using the m_ prefix to denote class data members is dangerous in code that has to compile on VxWorks 5.5 (which 3.15 does) because the net/mbuf.h header contains the following macro definitions: #define m_next mBlkHdr.mNext #define m_len mBlkHdr.mLen #define m_data mBlkHdr.mData #define m_type mBlkHdr.mType #define m_flags mBlkHdr.mFlags #define m_nextpkt mBlkHdr.mNextPkt #define m_act m_nextpkt #define m_pkthdr mBlkPktHdr #define m_ext pClBlk #define m_extBuf m_ext->clNode.pClBuf #define m_extFreeRtn m_ext->pClFreeRtn #define m_extSize m_ext->clSize #define m_extRefCnt m_ext->clRefCnt #define m_extArg1 m_ext->clFreeArg1 #define m_extArg2 m_ext->clFreeArg2 #define m_extArg3 m_ext->clFreeArg3 #define m_copy(m, o, l) m_copym((m), (o), (l), M_DONTWAIT) #define m_copym(m, o, l, w) netMblkChainDup(_pNetDpool, (m), (o), (l), (w)) #define m_freem(m) netMblkClChainFree(m) #define m_free(m) netMblkClFree(m) #define m_mbufs mNum #define m_drops mDrops #define m_wait mWait #define m_drain mDrain #define m_mtypes mTypes While the names in the original change all appear to be safe, I don't want us to start using this convention because we will then have to police commits more closely or risk build failures in the future when someone who doesn't know about or remember the issue can't or doesn't try building their code against VxWorks 5.5. I don't particularly like the this-> convention to mark member names either, but until the VxWorks 5.5 support requirement goes away the m_ convention is worse. Another common convention of using a leading underscore is not safe either, those names are reserved for the C/C++ implementation.
--------------------------------------------------------- EPICS Base - the central core of a control system toolkit --------------------------------------------------------- Copyright (c) 1991-2003 The University of Chicago, as Operator of Argonne National Laboratory. Copyright (c) 1991-2003 The Regents of the University of California, as Operator of Los Alamos National Laboratory. EPICS Base Versions 3.13.7 and higher are distributed subject to a Software License Agreement found in the file LICENSE that is included with this distribution. --------------------------------------------------------- Installation and release information can be found in the various files in the documentation subdirectory. Additional information about EPICS including mailing list archives and subscription instructions, documentation and training materials, additional components, links to other websites etc. is available on the EPICS home page at http://www.aps.anl.gov/epics/
Languages
C++
81.9%
C
8.6%
HTML
7.9%
Makefile
1.1%
DIGITAL Command Language
0.5%