You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@guacamole.apache.org by "Sertonix (Jira)" <ji...@apache.org> on 2025/10/15 13:37:00 UTC

[jira] [Updated] (GUACAMOLE-2153) GUAC_*_UTF16 have different results on big-endian system

     [ https://issues.apache.org/jira/browse/GUACAMOLE-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sertonix updated GUACAMOLE-2153:
--------------------------------
    Description: 
The `GUAC_*_UTF16` functions read the code points casting to a uint16_t pointer without using le16toh and the like which causes the results to vary between little- and big-endian machines which causes some tests to fail.

Since UTF-16 works with 16-bit values it has a byte order and that byte order is not well defined. There is a convention to use U+FEFF as first character which allows determining the endianess but it's commonly not present and doesn't seem to fit into the current code. The most common thing is to assume little-endian. If supporting both big- and little-endian UTF-16 is wanted one could create _UTF16LE and _UTF16BE variations of the functions.

  was:
The `GUAC_*_UTF16` functions read the code points casting to a uint16_t pointer without using le16toh and the like which causes the results to vary between little- and big-endian machines.

[https://github.com/apache/guacamole-server/pull/618] contains more details about endianess with UTF-16.


> GUAC_*_UTF16 have different results on big-endian system
> --------------------------------------------------------
>
>                 Key: GUACAMOLE-2153
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-2153
>             Project: Guacamole
>          Issue Type: Bug
>            Reporter: Sertonix
>            Priority: Minor
>
> The `GUAC_*_UTF16` functions read the code points casting to a uint16_t pointer without using le16toh and the like which causes the results to vary between little- and big-endian machines which causes some tests to fail.
> Since UTF-16 works with 16-bit values it has a byte order and that byte order is not well defined. There is a convention to use U+FEFF as first character which allows determining the endianess but it's commonly not present and doesn't seem to fit into the current code. The most common thing is to assume little-endian. If supporting both big- and little-endian UTF-16 is wanted one could create _UTF16LE and _UTF16BE variations of the functions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)