>>>1. What does Milan's code know that fbclient doesn't?
>>
>> Length of string in characters.

For CHAR(N) fileds string length in characters is always N, for VARCHAR(N)
string length stored in first two bytes of buffer.

> I understand that Milan derives that from 1) buffer size and 2) max
> number of bytes per character for the encoding used.

Opposite. Bytes_per_char is required to allocate buffer for XSQLVAR's
and used *before* obtaining query results.

> The latter is
> deduced from a charset id. Where does he get that charset id?

XSQLVAR::sqlsubtype have charset_id in low byte and collate_id in high byte

>>>2. Where does Milan's code get that info from?

See above

>>>3. Why doesn't fbclient have that info?
>>
>> Because fbclient doesn't know what UTF8 is and how convert it into
>> UCS. FB client is rather simple tosser of data from transport packets
>> into client structures and back.
>
> Does fbclient know the charset id?

See above

>>>4. Can FB be changed so fbclient can get that info in the future, and
>>>use it to trim the buffer to the right size before passing it to the
>>>client application?

It will require that fbclient know about all charsets supported by server.
Note, server could be another version that client, even higher.

>> Maybe, but so far nobody knows a good way to accomplish that.
>
> Can fbclient be provided with the charset id?

See above

...

>>>That should 1) reduce the amount of client application bugs and 2) make it easier for
>>>client application code to trim the buffer content correctly.

Client application already have all necessary info to do it

Regards,
Vlad