Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 13 Nov 2012 23:50:27 +0000

Andrew,

Consider the following little database:

record(stringout,"$(P)$(R)ReadID") {
    field(DTYP, "asynOctetWrite")
    field(OUT,  "@asyn($(PORT))")
    field(VAL,  "*IDN")

    field(FLNK, "$(P)$(R)ID")
}

record(waveform,"$(P)$(R)ID") {
    field(DTYP, "asynOctetRead")
    field(INP,  "@asyn($(PORT))")
    field(FTVL, "CHAR")

    field(NELM, "256")
}

Let's assume $(PORT) is the name of an asyn TCP or serial device.

The first record sends the *IDN command to a device, which returns a potentially long string from SCPI devices containing the model information.  The second record reads the response into a waveform record directly from a TCP or serial device.

In this case the NORD field of the waveform record will be set to the number of characters returned by the device.

IMHO this is not a far-fetched database.

So now clients will face two different meanings of NORD.

Dirk: Does streamDevice support reading long strings into a waveform record?  If so, does it set NORD to strlen(string), or strlen(string)+1?

Mark

________________________________________
From: Andrew Johnson [[email protected]]
Sent: Tuesday, November 13, 2012 3:56 PM
To: Mark Rivers; Tech-talk
Subject: Re: Long string support in CA clients and device support

Hi Mark,

On 2012-11-13 Mark Rivers wrote:
>
> So do we agree with Andrew's recommendation that NORD should including the
> trailing Nil, or should NORD be the actual number of elements that were
> read, and clients must be fixed to handle this if they want to use long
> string support?

Passing around long strings that don't have (or count) a terminating Nil byte
is inherently risky, although the danger is more likely to be annoying
(appending garbage or old text to the current text) than to induce crashes in
the IOC.

An aSub record subroutine is a client, and it's very easy for the subroutine's
author to not realize that the long string in their record's input field may
not be Nil-terminated.  The code that reads the input link into that field is
generic and can't add the Nil.  If the code calls strlen() on the buffer or
passes it into sprintf() without doing the termination dance it's going to
count the garbage.

I understand Eric's desire to not add zero bytes to data that Asyn reads in
through a serial or network port and that is obviously essential, but that's
not what you're proposing to do anyway.  If I've read your message correctly
asynPortDriver parameter strings are coming from internal sources, they are
not providing raw data from the port.  By counting the Nil when it is already
present you are reducing the work that the author of a 1-off aSub subroutine
has to do, and making the IOC code more robust.

- Andrew
--
READ CAREFULLY. By reading this email, you agree, on behalf of your
employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrink-wrap, click-wrap, browse-wrap, confidentiality, non-disclosure,
non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I
have entered into with your employer, its partners, licensors, agents
and assigns, in perpetuity, without prejudice to my ongoing rights
and privileges. You further represent that you have the authority to
release me from any BOGUS AGREEMENTS on behalf of your employer.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System