EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: EPICS on Tru64unix and HP-UX
From: "Jeff Hill" <[email protected]>
To: <[email protected]>, "'Andrew Johnson'" <[email protected]>
Cc: <[email protected]>, "'EPICS core-talk'" <[email protected]>
Date: Thu, 21 Dec 2006 15:34:09 -0700
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  <20062007  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·