Hello Kazuro,
Sorry about the delay responding. Part of the reason was a closure of the
lab here yesterday due to some significant snowfall here.
> > Ok, I'm still waiting for a comment from Jeff Hill on your patch and/or
> > the above compile error - we committed all of your other changes, but
> > this is Jeff's code so he gets to decide what to do about it.
The function overload supplied in the comBuf.h patch "bool push ( const char
* value )" satisfies the compiler's quest for a function with the signature
"bool push ( const char value [MAX_STRING_SIZE] )" but isn't 100% correct
because the implementation pushes the value of a pointer into the stream
instead of pushing a string of length MAX_STRING_SIZE into the stream.
I had a look at why this compiler appears to not be using "template < class
T > bool push ( const T & value )" for T set to epicsOldString. I think I
see the cause in osdWireFormat.h. I committed a fix to CVS. Please try the
latest version from the R3.14 branch in CVS when you get a chance in order
to confirm if my suspicions are correct.
Many thanks for your assistance with R3.14.9.
PS: I have attached the patch for your review.
PPS: I suspect that this matter is related to an issue detected by gcc 4.0
several weeks ago - which apparently wasn't 100% fixed.
Best Regards,
Jeff
cvs diff -r R3-14-2_branch:yesterday -r R3-14-2_branch -u -wb -i (in
directory
D:\users\hill\epicsMainTrunk\epics\base\src\libCom\osi\os\default\)
cvs diff: Diffing .
Index: osdWireFormat.h
===================================================================
RCS file:
/net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/osi/os/default/osdWireFo
rmat.h,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -c -u -w -b -i -r1.1.2.3 -r1.1.2.4
cvs diff: conflicting specifications of output style
--- osdWireFormat.h 5 Dec 2006 01:22:04 -0000 1.1.2.3
+++ osdWireFormat.h 21 Dec 2006 22:13:12 -0000 1.1.2.4
@@ -118,10 +118,11 @@
dst = tmp._f;
}
-inline void WireGet (
+template <>
+inline void WireGet < epicsOldString > (
const epicsUInt8 * pWireSrc, epicsOldString & dst )
{
- memcpy ( & dst, pWireSrc, sizeof ( dst ) );
+ memcpy ( dst, pWireSrc, sizeof ( dst ) );
}
template <>
@@ -147,10 +148,11 @@
# endif
}
-inline void WireSet (
+template <>
+inline void WireSet < const epicsOldString > (
const epicsOldString & src, epicsUInt8 * pWireDst )
{
- memcpy ( pWireDst, & src, sizeof ( src ) );
+ memcpy ( pWireDst, src, sizeof ( src ) );
}
template <>
***** CVS exited normally with code 1 *****
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, December 20, 2006 3:54 PM
> To: Andrew Johnson
> Cc: Kazuro FURUKAWA; [email protected]; EPICS core-talk; Jeff Hill
> Subject: Re: EPICS on Tru64unix and HP-UX
>
> Hello Andrew,
>
> Thank you for detailed investigation.
>
> >>> On Wed, 20 Dec 2006 16:05:53 JST, Andrew Johnson <[email protected]>
> wrote;
> > Hi Kazuro,
> >
> > Kazuro FURUKAWA wrote:
> > > For Tru64unix...
> >
> > > [1] comBuf.h
> > > I've tried it again without comBuf.h modification. And I've got
> > > the following error. I've changed the compiler features like
> > > -std {gun,ansi,ms,arm} and they gave me the same results. I don't
> > > know why the error occurs, and why my change cures the compilation.
> > >
> > > =====
> > > cxx -c -D_OSF_SOURCE -DUNIX -std gnu -pthread -ieee -O
> > > -I. -I.. -I../../../include/os/osf -
> I../../../include ../comQueSend.cpp
> > > cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
> > > variable "tmp" of incomplete type "WireAlias<const char *>".
> > > detected during:
> > > instantiation of "void WireSet(const T &, epicsUInt8 *)
> [with
> > > T=const char *]" at line 191 of "../comBuf.h"
> > > instantiation of
> > > "bool comBuf::push(const T &) [with T=const char
> *]" at
> > > line 144 of "../comQueSend.h"
> > > instantiation of
> > > "void comQueSend::push(const T &) [with T=const
> char *]"
> > > at line 112 of "../comQueSend.cpp"
> > > WireAlias < T > tmp;
> > > --------------------^
> > > cxx: Warning: ../comQueSend.cpp, line 327: pointless comparison of
> unsigned
> > > integer with zero
> > > if ( INVALID_DB_REQ ( dataType ) ) {
> > > ---------^
> > > cxx: Info: 1 error detected in the compilation of "../comQueSend.cpp".
> > > =====
> > >
> > > I've put the full compilation log with above error at
> > > <URL:http://www-linac.kek.jp/jk/osf/base-3.14.9pr2-make-osf-
> failed.log>
> >
> > Ok, I'm still waiting for a comment from Jeff Hill on your patch and/or
> > the above compile error - we committed all of your other changes, but
> > this is Jeff's code so he gets to decide what to do about it.
>
> I understand. The patch I added is nasty... There should be better
> approach.
>
> > > [2] snprintf()
> > > It seems the definition of the return value is different on Tru64.
> > > It simply returns the length of the buffer. The buffer contents
> > > are OK. The part of the results is like this.
> > > =====
> > > not ok 1 - epicsSnprintf(size=1) = 0
> > > ok 2 - buffer = ''
> > > ok 3 - length = 0
> > > not ok 4 - epicsSnprintf(size=2) = 1
> > > ok 5 - buffer = 'i'
> > > ok 6 - length = 1
> > > =====
> > > The return value should be 46. We may include a version of free
> > > snprintf() into the source tree, but...
> >
> > According to the C99 standard the return value from snprintf() is
> > supposed to be the number of characters that would have been written to
> > the buffer if it were large enough. We're used to different operating
> > systems having different semantics for snprintf(), which is why we make
> > it possible for each architecture to implement their own workaround.
> >
> > I'm not aware of any code in Base that will fail with the above issue,
> > but it would be good to fix this sometime - I won't hold up the R3.14.9
> > release waiting for it though.
>
> The document on Tru64unix says the current behavior. Thus, it is a
> feature, not a bug. They may have misunderstood the standard, or
> have followed a draft standard.
>
> I'm thinking about a dirty wrapper around their vsnprintf(), if I
> have time.
>
> > > [3] timer
> > > An example of the errore is like this.
> > > =====
> > > ./epicsTimerTest
> > > 1..33
> > > # Testing timer accuracy
> > > not ok 1 - percentError < messageThresh
> > > # delay = 1.000000 s, error = -0.007792 s (0.8 %)
> > > not ok 2 - percentError < messageThresh
> > > # delay = 1.100000 s, error = -0.007204 s (0.7 %)
> > > not ok 3 - percentError < messageThresh
> > > # delay = 1.200000 s, error = -0.007592 s (0.6 %)
> > > not ok 4 - percentError < messageThresh
> > > # delay = 1.300000 s, error = -0.007981 s (0.6 %)
> > > not ok 5 - percentError < messageThresh
> > > # delay = 1.400000 s, error = -0.007393 s (0.5 %)
> > > not ok 6 - percentError < messageThresh
> > > # delay = 1.500000 s, error = -0.007781 s (0.5 %)
> > > not ok 7 - percentError < messageThresh
> > > # delay = 1.600000 s, error = -0.008170 s (0.5 %)
> > > ok 8 - percentError < messageThresh
> >
> > > Without load, software with usleep() or setitimer() normally shows
> > > 0-2 millisecond accuracy. So the above discrepancies are large
> > > compared with my experiences. We have 7 alpha machines at KEKB
> > > and Linac. The numbers of processes are 200 to 600, and the load
> > > averages are 1 to 15. The results do not change much between
> > > machines. I don't know the origin of the errors.
> >
> > I regard the earlier timer tests not so much as an error as a warning,
> > and since your machines are running signficant numbers of processes I
> > would not be too worried by the above failures.
>
> [4] LDLIBS
> I realized another inconsistency, as I tried R3.14-CVS dated
> Dec.20 for native compiler (namely osf-alpha, instead of osf-alpha-gnu).
> I should have used the flag -pthread instead of "-D_REENTRANT
> -lpthread ..." consistently for cc and ld.
> The rule is correctly followed for STRICT targets but not for
> others.
> Also as a side effect(?) -lm is not used in OP_SYS_LDLIBS for some
> targets. epicsCalcTest for example fails to build with CVS-source.
> I had put "USR_SYS_LIBS += m" in CONFIG.Common.osf-alpha as a
> work-around in my patch, but maybe that is not clean. I may look
> in more although I don't yet understand when OP_SYS_LDLIBS is
> overwritten.
>
> Cheers.
> -----
> Kazuro FURUKAWA <[email protected]>
> Linac&KEKB, High Energy Accelerator Research Organization (KEK), Japan
> Telephone: +81-29-864-5200 x4316, Facsimile: +81-29-864-0321
- Replies:
- Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- References:
- Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Navigate by Date:
- Prev:
Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Next:
Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- 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: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Next:
Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|