Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 14 Nov 2012 17:42:27 -0500

Hi Mark & Eric,

On 2012-11-13 Mark Rivers wrote:
> Consider the following little database:
...
> So now clients will face two different meanings of NORD.

Yes, but I don't agree that it means there are two different meanings of NORD, 
which in all cases tells you how many elements are stored in the array.  A Nil 
byte is an integral part of a C string, so it should be included when copying 
a string.  Your ID waveform does not hold a C string however, it stores an 
array of characters, which you can convert into a proper string by appending a 
terminator.

Look at the following C definitions:
    char *str1   = "abcd";
    char str2[5] = "abcd";
    char str3[4] = "abcd";
    char str4[]  = {'a', 'b', 'c', 'd'};
    char str5[]  = "abcd";
The C compiler automatically adds a terminator to string literals everywhere 
that it can, so only str3 and str4 will not have a Nil terminator immediately 
following the 'd' in memory.  It can't for str3 because the storage allocated 
for the array is too small, and str4 is explicitly initialized with chars so 
it's not a string, but sizeof(str5) = 5 not 4; the compiler allocates space 
for the terminator because the array was initialized as a string.

All I'm asking you to do in asynPortDriver is just what the C compiler is 
doing for str2 and str5 above; when you have the ability to store a terminated 
string in the array without changing the meaning of the data, do so.

If you use the $ field modifier to access a DBF_STRING field as a char array 
(such as a CALC field, which in 3.15 is 80 characters long and thus too long 
for a DBF_STRING request to give you the whole string) the data you will get 
back is guaranteed to have a Nil terminator in it.  The same is true for any 
link field or record attribute such as .RTYP$.  None of those currently 
support dynamic array sizing of the char array, so the only way to know where 
the string data ends is to call strlen() on it to find the terminator (and if 
you didn't fetch all ca_element_count() elements you'd better stick a Nil byte 
at the end of your buffer so that strlen() doesn't run off the end).

Long strings were a kludge to get around the fixed length of the DBF_STRING 
definition without breaking network compatibility, and truly correct code that 
handles them must be careful.  By recommending that you count the Nil byte if 
you append one I'm merely trying to shore up the rickety construction so it 
doesn't collapse on top of our non-expert users as often as it might otherwise 
do.

You don't have to follow my recommendation at all (it is a recommendation, not 
a requirement) but if you do it might reduce the amount of frustration and 
swearing that occurs when someone writes incorrect code.

I'm done with discussing this topic, I need to work on the 3.14.12.3 pre-
release for next week.

- 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