Conversion utility in the API

[Adriano dos Santos Fernandes]

Hi!

It's very difficult for client libraries to implement conversion of
types in the same manner as implemented internally by Firebird (client
or engine). There are many complexities like conversion of floating
point types and integral scaled ones, for example.

It's not sufficient to let client change message field types and let
Firebird do it.

Usually, libraries have methods like getInt, getString, etc for
individual columns and nobody can anticipate what the developer is going
to call. The same for setters.

Therefore I propose new utility function:

interface Util : Versioned
{
...

void convert(
Status status,
uint sourceType,
uint sourceScale,
uint sourceLength,
const void* source,
uint targetType,
uint targetScale,
uint targetLength,
void* target);
}

It will be very raw, as anyone that can already read/write data to
messages can use this function with buffers and read/write data to it.
It will be thin wrapper for a CVT_move call. It should not work for blobs.


Adriano

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 04.10.2025 14:19:
> It's not sufficient to let client change message field types and let
> Firebird do it.

Why? What's wrong with it?

--
WBR, SD.

[Denis Simonov]

Good idea. What about string encoding conversion? On the client side, Unicode encoding UTF16 (LE/BE) is often used. It would be nice to provide a tool that enables this conversion. I understand that this can be done with third-party libraries like icu/iconv/winapi... But the Firebird client already loads the ICU library for time zone support. So why not make life easier for developers when working with different string encodings?

суббота, 4 октября 2025 г. в 15:22:55 UTC+3, Dimitry Sibiryakov:

[Dimitry Sibiryakov]

Denis Simonov wrote 04.10.2025 15:27:
> On the client side, Unicode encoding UTF16 (LE/BE) is often used. It would be
> nice to provide a tool that enables this conversion.

It would be even nicer to support UTF-16 encoding for string data. Note that
charsets.h
(https://github.com/FirebirdSQL/firebird/blob/83c4c5fc5e366eceb00e1a56b95c20932c544b2c/src/intl/charsets.h#L87)
already mention it but Adriano never finished what he started 20 years ago.

--
WBR, SD.

[Adriano dos Santos Fernandes]

I was waiting for a troll given others work to create commercial products and not given anything back to Firebird (other than bug code) would do it.

Adriano

[Denis Simonov]

I don't need server-side support for VARCHAR(N) CHARACTER SET UTF16, but it would be very nice to be able to specify UTF16 encoding in the connection itself.

And yes, I'm positive about `Util::convert`. In simple cases (one-time call), it can be more convenient than changing field types in the message.

суббота, 4 октября 2025 г. в 17:40:37 UTC+3, Adriano dos Santos Fernandes:

[Adriano dos Santos Fernandes]

Good idea. What about string encoding conversion? On the client side, Unicode encoding UTF16 (LE/BE) is often used. It would be nice to provide a tool that enables this conversion. I understand that this can be done with third-party libraries like icu/iconv/winapi... But the Firebird client already loads the ICU library for time zone support. So why not make life easier for developers when working with different string encodings?

I don't think we should.

It doesn't matter to have ICU in the client. The client do not have fbintl integration.

Also, ICU is optional.

And finally, there is already the connection charset and in general a client do not need to get data in multiple encodings. Developers do not need to call methods like getString(column, encoding).

Adriano