Skip to content

CI: one workflow, fewer macOS jobs, more code pages; Windows path separators, conversion state - #205

Merged
JeromeMartinez merged 3 commits into
MediaArea:masterfrom
JeromeMartinez:CI_Codepages
Nov 7, 2026
Merged

JeromeMartinez merged 3 commits into
MediaArea:masterfrom
JeromeMartinez:CI_Codepages

Conversation

@JeromeMartinez

Copy link
Copy Markdown
Member

One workflow for the checks, fewer jobs (1 macOS job instead of 6), more code pages, and the fixes found with them.

CI:

  • The file name checks are in the Checks workflow; FileName_Checks.yml is removed.
  • One macOS job builds with and without Unicode, with the autotools and CMake; the Linux, Alpine and FreeBSD jobs cover both modes too. Android API 24, 26 and 28 (one per function boundary).
  • A new push cancels the run of the previous one on the same branch or pull request, except on master.
  • Code pages: GB18030 locale, and on Windows the code page of the system plus UTF-8 and cp932 set by the manifest of the test program.

Fixes:

  • FileName, Dir: "/" is accepted on Windows in addition to "" (path, name, extension, directory listing). FileName_PathSeparator is kept for the programs which use it, ZenLib does not use it anymore. Without Unicode on Windows, the second byte of a double-byte character (e.g. 0x95 0x5C in cp932) is no more taken as a path separator.
  • Ztring: From_Local() and To_Local() use their own conversion state; the one of the C library is undefined after an invalid string, and with GB18030 on FreeBSD and macOS all next strings, even ASCII ones, were empty.

…character

On Windows, Path_Get(), Name_Get(), Extension_Get(), the setters and the
directory listing accept "/", which Windows accepts as path separator, in
addition to "\". FileName_PathSeparator is kept for the programs which use
it, but ZenLib does not use it anymore.

Without Unicode on Windows, names are in the code page of the system, and
with a double-byte one such as cp932, the second byte of some characters
is "\", e.g. 0x95 0x5C for U+8868: these functions took it as the last
path separator.
From_Local() and To_Local() used the internal state of the C library,
which is undefined after a string which is not valid in the encoding of
the locale. Some implementations then keep its last bytes, e.g. GB18030
on FreeBSD and macOS: all the next strings, even ASCII ones, gave an
empty string, and the listing of a directory with such a name was empty.
The file name checks are in the Checks workflow: one macOS job builds with
and without Unicode, with the autotools and CMake, and the Linux, Alpine
and FreeBSD jobs cover both modes too. A new push cancels the run of the
previous one on the same branch or pull request, except on master.

The test program checks the conversions with the GB18030 locale, and with
any locale or code page which is neither ASCII nor UTF-8 against the C
library or the system, with two Japanese names. On Windows, it runs with
the code page of the system, and with UTF-8 and cp932 set by the manifest
of the program; without Unicode with cp932, it checks a name whose second
byte is "\". It also checks the path separators of the FileName functions.
@JeromeMartinez
JeromeMartinez merged commit 73b7480 into MediaArea:master Nov 7, 2026
16 checks passed
@JeromeMartinez
JeromeMartinez deleted the CI_Codepages branch November 7, 2026 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant