> -----Original Message-----
> From: Joe Amuquandoh
>
> In IMAGE DBGET, what happens if the LIST of ITEMS is longer
> than the BUFFER being put into.
> Besides the obvious truncation, is there any impact?

By this, I presume you mean you have either:

  1) a pointer to an area of memory allocated to [say] 256 bytes, but the
textual-names-plus-commas exceeds 255 characters in length

- or -

  2) a pointer to an area of [again, for example] 32 "words" [16-bit], but
more than 32 "fields" in the data set

Truncation may or may not occur in the first case -- it depends on the
language you're using and the way the compiler behaves [although typically
truncation will occur]  If that happens, IMAGE will complain of a bad or
missing item when parsing the image-list.  Note that if the
compiler/language you are using doesn't care that you've only defined a 256
byte buffer and writes beyond that point, IMAGE won't complain [it will have
the entire list], but you will have "corrupted" the value of any variables
that reside in memory beyond that buffer... [typically related to the DBxxx
action anyway, but still a pain when it happens]

In the second case, IMAGE is looking for [I believe] a zero value to
indicate the "end of the list" -- again, depending on whether or not the
language you are using truncate-or-corrupts, you will get one of the
following:

   a) not all the fields returned [not a big deal, but confusing...]
   b) everything you were expecting [but other variables trashed when you
built the list, for the same reason as above]
   c) additional fields you were NOT expecting [more on this in a moment]
   d) a missing/invalid field error
   e) a "bounds violation" from the IMAGE call

"A" above occurs if the language you are using doesn't write beyond the last
element of the "array" you are using AND two bytes of "zeros" immediately
follow that array in memory.  Likewise "B" occurs when the language/compiler
blithely ignores your buffer size and writes everything you tell it,
including a terminating "zero" value.  For items C, D & E, this occurs
because IMAGE keeps looking for the zero to terminate the list AND the
language you are using "recognizes" that you're putting more elements into a
[half]word array than you defined [and doesn't cause a compile/run time
error].  IMAGE will use "whatever value" appears in memory following the end
of your item array -- legal field values (c), values that do NOT correspond
to a field in the dataset (d), or the end of "defined" memory for your
process (e).

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *