Re: eclg -C ORACLE breaks data

(sorry for the wrong subject..)

At Mon, 17 Apr 2023 17:00:59 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Mon, Apr 10, 2023 at 05:35:00PM +0900, Kyotaro Horiguchi wrote:
> > This results in overwriting str[-1], the last byte of the preceding
> > numeric in this case, with 0x00, representing the digit '0'. When
> > callers of ecpg_get_data() explicitly pass zero as varcharsize, they
> > provide storage that precisely fitting the data.
> 
> Good find, that's clearly wrong.  The test case is interesting.  On
> HEAD, the processing of the second field eats up the data of the first
> field.
>
> > However, it remains
> > uncertain if this assumption is valid when ecpg_store_result() passes
> > var->varcharsize which is also zero. Consequently, the current fix
> > presumes exact-fit storage when varcharsize is zero.
> 
> Based on what I can read in sqlda.c (ecpg_set_compat_sqlda() and
> ecpg_set_native_sqlda()), the data length calculated adds an extra
> byte to the data length when storing the data references in sqldata.
> execute.c and ecpg_store_result() is actually much trickier than that
> (see particularly the part where the code does an "allocate memory for
> NULL pointers", where varcharsize could also be 0), still I agree that
> this assumption should be OK.  The code is as it is for many years,
> with its logic to do an estimation of allocation first, and then read
> the data at once in the whole area allocated..
> 
> This thinko has been introduced by 3b7ab43, so this needs to go down
> to v11.  I'll see to that.

Thanks for picking this up.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center