Experimental Physics and
Industrial Control System

Johnny Tang <[email protected]> · Tue, 7 Mar 95 17:35:29 EST

=============================================================
Johnny Tang     Voice: (804)249-7239  E-Mail: [email protected]
Continous Electron Beam Accelerator Facility
12000 Jefferson Avernue, MS 85A
Newport News, Va 23606
=============================================================
Mailer: Elm [revision: 70.85]

  Andrew,

  What you need probably is subArray record (NOT aai or aao )wrriten 
by Carl Lionberger, refer to "EPICS IOC Record Reference Manual" for 
Release 3.12. 

  Again, the aai and aao are for CEBAF RF application special use. 
Its documentation is in ftp.cebaf.gov: /pub/epics/doc/rec/CebafRfRecSup.ps.
(It just has been installed there.)

  I do realize the aai and aao recSup code need be reviewed and some clean up.
Thanks for the comments.

  Johnny Tang

> 
> >   If you find any bugs in the code, please report to us, we would appreciate 
> it.
> 
> I am worried about what happens if you put a different amount of data into an 
> array than it has reserved space for.  At initialisation time the init_record 
> routines in the device support layer calloc some space according to the setting 
> of nelm at the time, and put the memory pointer into bptr.  I can't see any 
> reallocation of this space anywhere, but it is possible to change nelm using the 
> put_array_info RSET routine.  Now I guess it is up to Database-Access to 
> actually put new values into the array (using the cvt_dbaddr record support 
> routine to get details of the array), but I don't know what would happen if you 
> tried to put a longer or shorter array than that defined.  I guess it wouldn't 
> write past the declared end of the array, so there shouldn't be a problem there, 
> however there may be if you ever write *fewer* elements because you lose all 
> knowledge of how much space was originally allocated when database access calls 
> the record put_array_info routine.  I may be totally wrong here because I don't 
> know how database access works, and I'm happy to be corrected if I have 
> misunderstood it.
> 
> Record support defines the dset to contain just 5 routines, but your device 
> support layers declare 6 (they add special_linconv, but don't use it).
> 
> There is another bug in your Camac device support routines, although you will 
> only have seen it if you use strings.  Around line 111 you have the code
> 
> if (paao->ftvl == 0)
>     paao->bptr = (char *)calloc(...);
> paao->bptr = (char *)calloc(...);
> 
> There should be an 'else' before the second calloc statement, or it will call 
> calloc twice for a string array and overwrite the first buffer address.  Why not 
> just set sizeofTypes[0] = MAX_STRING_SIZE in the first place, then you don't 
> need the test anyway?  I'm not very keen on the sizeofTypes[] array being in the 
> record support code or in devCamac.h by the way, although I can't find any other 
> header files which declare anything equivalent (other than db_access.h which I 
> believe is obselete and probably shouldn't be used) so I guess there's little 
> alternative for the moment.
> 
> I don't understand why the device support routines read_aai and write_aao return 
> CONVERT and/or DO_NOT_CONVERT as the record never looks at the return status.  
> According to the comment in the record for these routines they should return -1 
> or 0, while devCamac.h defines DO_NOT_CONVERT as 2.  There also appears to be no 
> way for device support to return an undefined result as the process routines 
> always set udf to FALSE.
> 
> - Andrew
> 
>           ,_}\_.        Andrew Johnson, Technology Division
>          /      \       Royal Greenwich Observatory
>  ~~~~~~~| ,--/;. )~~~~  Madingley Road, Cambridge, UK
>     .,  |/  (/  U       Phone: +44 (0)1223 374823
>   .`., /_\ . .          Email: [email protected]
>      wwWWWww'           WWW: http://www.ast.cam.ac.uk/~anj/
> 
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System