(sorry for the wrong subject..) At Mon, 17 Apr 2023 17:00:59 +0900, Michael Paquier <mich...@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
