On 13-2-2012 16:33, Dmitry Yemanov wrote: >> * Is the size being allocated to data for SQL_VARYING right, shouldn't >> the actual size of the byteArray[1] + 3 (or 2) be sufficient instead of >> sqllen + 3 (especially for UTF8 and for strings shorter than the maximum >> size this is larger than necessary) > > length(byteArray) + 2
Does SQL_VARYING require the sqllen to be updated as well, or can that be left as it was originally set by isc_dsql_describe_bind? >> * For all datatypes other than SQL_VARYING, it is first storing >> byteArray size and then overwriting that with the byteArray, so actually >> storing that size first is unnecessary, right? > > I'm not sure I understand you here. This turned out to be the actual bug I was investigating; the Jaybird code for SQL_TEXT was doing: *((short*)currentXsqlvar.sqldata) = (short)byteArray.Size(); memcpy( currentXsqlvar.sqldata, byteArray.Read(), byteArray.Size()); Which is (sort of) an overflow for single character, one byte, UTF-8 and messes up the padding and causing a string truncation error. -- Mark Rotteveel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
