Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 20 Dec 2006 16:05:53 -0600

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.

[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.

[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.

Thanks,

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System