Experimental Physics and
Industrial Control System

[email protected] (Marty Kraimer) · Thu, 21 Sep 1995 14:18:50 -0500

> From [email protected] Thu Sep 21 13:46 CDT 1995
> Date: Thu, 21 Sep 1995 13:45:52 -0500
> From: [email protected] (Tim Mooney)
> To: [email protected], [email protected]
> Subject: Re: Engineering Units
> Content-Type> : > text> 
> Content-Length: 859
> 
> re...
> > ...problem with get_units.
> > ...
> > What we can do for now is to define a symbol MAX_UNITS_SIZE in dbDefs.h
> > and change all record support modules and ascii files to use this symbol.
> > Then when we go to next major EPICS release number we can just change
> > MAX_UNITS_SIZE and have everything automatically support units strings
> > of 16 characters.
> > 
> > Comments?
> 
> I think dbGet() should guarantee CA clients a null-terminated string by
> writing a null into the last available element of the units-string
> space.  If we do this, we don't need to patch any existing code (but
> we do lose one character of units information).
> 
> Defining MAX_UNITS_SIZE, and patching what record-support code we can
> find, will not guarantee a null-terminated string.  Eventually, some CA
> client will crash in response to user input, after working fine for
> months.

The problem is that many users may already have 8 character unit fields that
work just fine with medm, ed, and other standard tools. They will all of a
sudden have 8th character chopped off. 

I thought of something else. Maybe we want to leave ascii def files
with length of 16 and just change recSup code to copy up to
MAX_UNITS_SIZE chanacters. That way any databases that have longer
units strings will work properly in the future and for now just have
units chopped off at 8 characters.

Marty Kraimer 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System