Andrew Johnson b7f8f17227 blockingSockTest: Undo member renames using m_ prefix
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.
2014-08-02 14:02:43 -05:00
2013-10-15 11:32:31 -05:00
2012-12-18 15:44:35 -06:00
2010-10-12 11:27:17 -05:00

---------------------------------------------------------
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%