PR# 14568 Retrieve of corrupted file created by independent_store gets floating point exception

Based on code inspection (and confirmed with the attached example), retrieving
a file created by `independent_store' that happens to be corrupted in a 
particular way can cause a floating point exception, due to a divide by zero.

The cause appears to be two lines in retrieve.c (in `ridr_multi_ptr' and
`old_ridr_multi_int') that are

   cap = idrf_buffer_size / s;

Local `s' is of type char and its value is read from the file, so if the file
is corrupted and the length `s' represents is replaced by `%U' we get a
divide by zero.

Although you may not be able to prevent all such crashes, this one seems to
be quite preventable by calling `eraise' with EN_RETR.

Compile with attached classes on 32-bit system.  Execute system.
Execution terminates with a floating point exception.
Class should probably be adjusted to calculate the offset into which the '%U'
character is stored, rather than using a constant that won't work on some
platforms (particularly 64-bit platforms) or if store format changes.

I modified the original test to take an argument, which is the position in
the file containing the independent stored object at which to put a null
(%U character).  Depending on what argument I pass (this is Solaris SPARC
32-bit) on 6.4.76313, I get different failure results.  It seems that from
a programmers point of view, I should always get "retrieve exception".  
Otherwise I have to catch all exceptions when retrieving.  Certainly, the
"floating point exception" (last case below) seems to be a bug.

With argument of 0:

Retrieve exception 
(Program caught retrieve exception, rescued it and printed this.  Seems like
 a correct result).

With argument of 4:

-------------------------------------------------------------------------------
RAW_FILE            c_retrieved
<00000000016CAC20>  (From FILE)            I/O error.                    Fail
-------------------------------------------------------------------------------

With argument of 10:

---------------------------------------
....
Output truncated, Click download to get the full message

Attachments for problem report #14568