From: hades <hades>
Date: Sun, 10 Sep 2000 12:05:24 +0000 (+0000)
Subject: *** empty log message ***
X-Git-Url: https://jspc29.x-matter.uni-frankfurt.de/git/?a=commitdiff_plain;h=6721da15c051a256b6cd76e0e9afc6699e75f75a;p=daqdata.git

*** empty log message ***
---

diff --git a/allParam/README b/allParam/README
index 9153c1d..288bf67 100644
--- a/allParam/README
+++ b/allParam/README
@@ -193,6 +193,9 @@ the exact number of result elements but only a upper limit for that. On the
 other hand if you want to retrieve an integer array and only one of the
 values seems to be no integer (according to strtoul(3)), the return value is
 -1 and the content of the supplied array (valueia in our example) is undefined.
+  Be aware of the fact that there is a magic border for the number of array
+elements that can be transferred at once. This is PARAM_MAX_ARRAY_LEN and
+currently set to 128.
   Take also care of what kind of pointer type you have to supply in the
 different value fields:
 - Param_getString() needs a char *,
@@ -208,6 +211,11 @@ different value fields:
 - The treatment of values out of bounds (e.g. strings longer than the foreseen
   PARAM_MAX_NAME_LEN and PARAM_MAX_VALUE_LEN) is not checked in the testsuite
   yet.
+- EPICS has a much more strict limitation on the length of PV names (28
+  including the prefix 'HAD:PARAM:'). So the full length of 127 + 127
+  characters for name + idx cannot be used when including a libcaParam.a in the
+  data path. Also libfileParam.a only supports an overall length of 127 for the
+  string s when s is produced via sprintf(s, "%s(%s%d)", name, idx, i).
 - As a fifth data type, blobs (binary large objects) should be supported in the
   future.