[refactor][utils] Replace thread-unsafe strerror() with C++ standard error message API

[zhaohai666]

Summary

The C strerror() function for system error reporting violates C++ idioms and is not thread-safe under multi-threaded environments. This PR refactors all relevant error message generation to use standard C++ error utilities.

Changes

1. apps/uab/loader/src/main.cpp
   Substitute ::strerror(errno) with std::generic_category().message(errno) in error logging paths of fork() and waitpid().

2. libs/oci-cfg-generators/src/linglong/oci-cfg-generators/container_cfg_builder.cpp
   Replace strerror(errno) with std::generic_category().message(errno) for error reporting of readlink() and mount() invocations.

Modified Files

• apps/uab/loader/src/main.cpp
• libs/oci-cfg-generators/src/linglong/oci-cfg-generators/container_cfg_builder.cpp

Advantages

1. Aligns with modern C++ error handling practices instead of outdated C interfaces
2. Fixes thread-safety hazards caused by non-reentrant strerror()
3. Provides consistent system error descriptions through standard C++ error category APIs

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: zhaohai666

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

Hi @zhaohai666. Thanks for your PR.

I'm waiting for a OpenAtom-Linyaps member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[gemini-code-assist]

Code Review

This pull request replaces the usage of strerror(errno) with std::generic_category().message(errno) for error reporting across several system calls, including fork, waitpid, realpath, and mount. The reviewer feedback suggests that std::system_category() is conceptually more appropriate than std::generic_category() for these operating system-level errors, as it is specifically designed to handle and map system-specific error codes correctly.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

For system call errors (such as those from fork()), std::system_category() is conceptually more appropriate than std::generic_category(). std::system_category() is specifically designed for errors reported by the operating system, whereas std::generic_category() is for portable, generic error codes (equivalent to std::errc). Using std::system_category() ensures that any system-specific error codes are correctly mapped to their corresponding error messages.

Suggested change

	std::cerr << "fork() err: " << std::generic_category().message(errno) << std::endl;
	std::cerr << "fork() err: " << std::system_category().message(errno) << std::endl;

[gemini-code-assist]

For system call errors (such as those from waitpid()), std::system_category() is conceptually more appropriate than std::generic_category(). std::system_category() is specifically designed for errors reported by the operating system, whereas std::generic_category() is for portable, generic error codes (equivalent to std::errc). Using std::system_category() ensures that any system-specific error codes are correctly mapped to their corresponding error messages.

Suggested change

	std::cerr << "waitpid() err:" << std::generic_category().message(errno) << std::endl;
	std::cerr << "waitpid() err:" << std::system_category().message(errno) << std::endl;

[gemini-code-assist]

For system call errors (such as those from realpath()), std::system_category() is conceptually more appropriate than std::generic_category(). std::system_category() is specifically designed for errors reported by the operating system, whereas std::generic_category() is for portable, generic error codes (equivalent to std::errc). Using std::system_category() ensures that any system-specific error codes are correctly mapped to their corresponding error messages.

                    return LINGLONG_ERR(fmt::format("Failed to read symlink {}: {}",
                                                    resolvConf,
                                                    std::system_category().message(errno)));

[gemini-code-assist]

For system call errors (such as those from ::mount()), std::system_category() is conceptually more appropriate than std::generic_category(). std::system_category() is specifically designed for errors reported by the operating system, whereas std::generic_category() is for portable, generic error codes (equivalent to std::errc). Using std::system_category() ensures that any system-specific error codes are correctly mapped to their corresponding error messages.

        return LINGLONG_ERR(fmt::format("failed to mount {}: {}",
                                        mount.source.value(),
                                        std::system_category().message(errno)));