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.
The string comparison functions epicsStrCaseCmp() and
epicsStrnCaseCmp() were returning incorrect results
when the strings did not match.
These functions now match their BSD equivalents, and
have working tests to confirm their operation.
Xiaoqiang Wang proposed some fixes that allow static builds on
the MinGW targets to succeed. Some additional changes made to
blockingSockTest.cpp also clean that up.
Fractional seconds could round-up to .000 without
incrementing the integer seconds.
We can't actually do the latter, so we prevent the
roll-over and clamp at all 9's instead.
Idea from Eric Norum.
VxWorks 6.x can make environment variables private to each
thread, which doesn't work too well.
A test failure on VxWorks explains how to change the image
configuration to fix this.
o suprressed some compile time warnings in bucketLib.c
o cleaned up cxx templates README
o removed use of tsMinMax from libCom in favor of the standard library
(calls to tsMinMax still exist in other components in base, but they are being removed)
o removed sharable library export of certain private member functions from class fdManager
o fixed aToIPAddr to correctly lookup all of the different IP addresses string types on all OS types
independent of the OS interfae variations
o removed use of inet_aton from vxWorks implementation of hostToIPAddr
o this function is for converting a host name to an ip address _only_
o the aToIPAddr wrapper is supposed to do the dotted ip ascii string to ip address structure
conversion independent of OS spoecific interface variations, when it works correctly
o fixed some spelling issues in comments
o added additional optimizations for processors w/o floating point ALU to addNanoSec in epicsTime
o removed tabs and junk comments from win32 osdProcess.c
o moved PLL update in win32 osdTime.c from timer to a dedicated thread
o added missing epicsExportShared symbols define to osiNTPTime.c
o fixed server ctor should not modify arguments of its caller in blockingSockTest
o removed sunpro specific ifdef nolomger needed from epicsTimeTest.cpp
Hostnames that begin with one or more digits were not being looked up
by name, causing problems at BNL.
This commit also changes the vxWorks implementation of hostToIPAddr()
to use inet_aton() instead of inet_addr().
Remove C++-isms.
Make internal routines static when duplicate names appear
in the epicsMutexTest.cpp code; on vxWorks and RTEMS all
test programs get linked into a single binary.
