Re: StreamDevice Checksum formatting bug

[Zimoch Dirk via Tech-talk <tech-talk at aps.anl.gov>]

Check with ldd which libstream.so file your IOC uses and if that is the same
file that the streamApp test IOC uses.
Then use nm to see if ref_RegexpConverter is included:
$ nm libstream.so | grep ref_RegexpConverter
0000000000053880 D ref_RegexpConverter

On Wed, 2025-02-19 at 08:02 +0000, Zimoch Dirk via Tech-talk wrote:
> StreamDevice uses a small script (src/makeref.pl) to generate a file “streamReferences” which is included by StreamCore.cc and contains code to call the initialization functions for all the converters. Check if your generated O.*/streamReferences contains ref_RegexpConverter. It should, because you wrote you have regex in the streamApp test IOC. But then, I do not understand why you would not have it in your IOC. At least if you link to the same support library libstream.so as the test IOC. Are you sure you have built your IOC with the same version of the support library as the test IOC is built with?
> 
> 
> > On 18 Feb 2025, at 18:38, Baily, Scott A <sbaily at lanl.gov> wrote:
> > 
> > I'm having trouble getting the pcre converter to show up in my application.  The running dbior for the streamApp test IOC shows the regex converter, but with my IOC it doesn't.   ldd does show the libpcre and libpcre2 as being loaded in both cases. I'm not sure what's missing.
> > 
> > -----Original Message-----
> > From: Zimoch Dirk <dirk.zimoch at psi.ch> 
> > Sent: Monday, February 17, 2025 1:37 AM
> > To: Baily, Scott A <sbaily at lanl.gov>; tech-talk at aps.anl.gov
> > Subject: [EXTERNAL] Re: StreamDevice Checksum formatting bug
> > 
> > On Mon, 2025-02-17 at 08:31 +0000, Zimoch Dirk via Tech-talk wrote:
> > > On Sun, 2025-02-16 at 23:11 +0000, Baily, Scott A via Tech-talk wrote:
> > > > I realize that to represent all possible 16-bit checksums as a decimal number one would need 5 characters, but my device only uses 4. None of the strings are longer than 78 characters so it won’t overflow, but there doesn’t seem to be a way to specify the field width for a checksum (the width and precision specifiers are used for other purposes).
> > > 
> > > Hi Scott
> > > 
> > > I checked the source code and found this:
> > > // get number of decimal digits from number of bytes: ceil(bytes*2.5) 
> > > So for 16 bits it is 5 digits as you found out.
> > > 
> > > What you can do is to post-process the output using a regular expression:
> > > "%+<sum16>#-5/.(.*)/\1/"
> > I lost a % here. Should be:
> > "%+<sum16>%#-5/.(.*)/\1/"
> > 
> > > This replaces (after inserting the 5 digit checksum) the last 5 
> > > characters with whatever follows the first of those 5 chars (i.e. the 
> > > last 4 digits of the checksum).
> > > 
> > > Reading such a checksum needs some pre-processing:
> > > "%#-4/.*/0&/%+<sum16>"
> > > This replaces (before parsing the 5 digit checksum) the last 4 
> > > characters with itself prefixed by a 0.
> > > 
> > > Both cases will of course produce nonsense if the sum exceeds 4 chars.
> > > 
> > > Dirk
> > > 
> > > > From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Baily, 
> > > > Scott A via Tech-talk <tech-talk at aps.anl.gov>
> > > > Sent: Friday, February 14, 2025 11:10:08 AM
> > > > To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> > > > Subject: [EXTERNAL] StreamDevice Checksum formatting bug
> > > > 
> > > > I seem to be having a problem with the formatting of 16-bit checksums from StreamDevice 2.8.25.   When I use a string that ends with “%+<sum16>” in the protocol file, I get the correct checksum in ascii characters as expected, but I have an extra leading 0  (5 characters instead of 4).  A checksum that should be “0389” is written as “00389”   A similar problem seems to be happening when reading (seems to be expecting an extra leading zero).  I can work around this because I know what will be sent and can ignore the checksum on reads,.  Has anyone else had this problem? If this is working correctly for you, what version of StreamDevice are you using?