Re: R3.14.8 testing

[Marty Kraimer <mrk@aps.anl.gov>]

I did a cvs update and rebuild.
exampleApp still crashes.

There are still lots of warning messages like

/fdmgr/fdmgr.cpp
"../../../src/libCom/fdmgr/fdManager.h", line 171: Warning: Conversion 
of 64 bit type value to "const unsigned" causes truncation.
"../../../src/libCom/fdmgr/fdManager.h", line 171: Warning: Conversion 
of 64 bit type value to "const unsigned" causes truncation.
"../../../src/libCom/fdmgr/fdmgr.cpp", line 33: Warning: Conversion of 
64 bit type value to "const unsigned" causes truncation.


I think we should create 3.14.8 and take care of this later.
I am concerned that fixing the 64 bit problems will in turn cause new bugs.

Marty


Jeff Hill wrote:

> > I get many many warning messages like:
> >
> > "../../../include/epicsTime.h", line 328: Warning: Conversion of 64 bit
> > type value to "unsigned" causes truncation.
> >    
>
> This is because the epicsTime has a 64 bit unsigned seconds field and the
> network time stamp has a 32 bit unsigned seconds' field. I committed a fix
> (which just suppresses the warning allowing truncation by design to
> continue). Here is the comment in the source code.
>
>    // epicsTime::secPastEpoch is based on ulong and has much greater range 
>    // on 64 bit hosts than the orginal epicsTimeStamp::secPastEpoch. The 
>    // epicsTimeStamp::secPastEpoch is based on epicsUInt32 so that it will 
>    // match the original network protocol. Of course one can anticipate
>    // that eventually, a epicsUInt64 based network time stamp will be 
>    // introduced when 64 bit architectures are more ubiquitous.
>    //
>    // Truncation usually works fine here because the routines in this code
>    // that compute time stamp differences and compare time stamps produce
>    // good results when the operands are on either side of a time stamp
>    // rollover as long as the difference between the operands does 
>    // not exceed 1/2 of full range.
>
>
>