Re: Libunicode

[Paolo Redaelli]

Il 06/01/22 22:35, Raphael Mack ha scritto:

> Sounds great for me. In this case I think we should not go with a
> simple generated wrapper, but have to really integrate it to be used
> with the manifest unicode strings U"", we should support utf-x encoded
> source files with direct unicode characters and not to forget a good
> set of test cases and examples to make it easy to use and robust.
>

I didn't dare proposing such a change. 😁

Yet I think we should, as Unicode is a basic need of todays standards.

I suggest to statically link it in order to avoid a runtime dependency.

In fact I think it is a good thing that programs compiled by liberty do not have any dependencies other than libc.

Yet I would rather avoid the approach of GoLang of statically linking.

Last time I compiled obs-cli ( https://github.com/muesli/obs-cli ) a simple command line tool made in golang to control remotely OBS (Open BroadCaster Studio) it created a 6,0MB binary from 26758 bytes of source. A stripped binary.

Also binaries made by Liberty aren't usually lean'n'slim, but I would rather avoid to statically link everything, being unicode support a notable exception, at least initially. Currently libunistring is a 2,3Mb static library or a 1,6Mb dynamic one. A good design would allow to let the developer choose if libunistring shall be linked statically or dynamically.

UNICODE_STRING is externally a TRAVERSABLE[INTEGER] and internally uses a NATIVE_ARRAY[INTEGER_16] UTF-16NE encoded.

libunistring supports Unicode strings in three representations:

• UTF-8 strings, through the type ‘uint8_t *’. The units are bytes (uint8_t).
• UTF-16 strings, through the type ‘uint16_t *’, The units are 16-bit memory words (uint16_t).
• UTF-32 strings, through the type ‘uint32_t *’. The units are 32-bit memory words (uint32_t).

which one shall we support?

I would make UNICODE_STRING deferred with UTF8_STRING, UTF16_STRING and UTF32_STRING as effective heirs, where current UNICODE_STRING would became the new UTF16_STRING.

I also searched eiffel.org and gobo eiffel for some hints. Aren't they the "professionals"?

I wasn't able to find a browsable documentation of their Unicode classes. My fault or theirs?

It seems to me that you, in your spare time and working almost alone provides better documentation for Liberty classes.