I don't think it would conflict with gnulib. I took a quick look at gnulib's string.h.in, and I think it may use existing mbs* functions if they meet gnulib's expectations. I see no reason to define mbs* functions which would behave differently from what gnulib expects. If anything, gnulib will simply end up replacing them.
- Kirill Makurin ________________________________ From: LIU Hao Sent: Friday, December 19, 2025 6:22 PM To: Kirill Makurin Cc: mingw-w64-public Subject: Re: [Mingw-w64-public] work-in-progress POSIX API library for native Windows 在 2025-12-17 23:05, Kirill Makurin 写道: > This is a good point. > > I know that, for example, gnulib has a module which provides mbs* equivalents > of str* functions. Maybe it > would be better to provide similar mbs* functions as extensions, rather than > replacing standard str* > functions. I was considering that, but I didn't make up my mind so far. > > In fact, I have internal "p32_private_str*_l" version of each standard str* > function, and what I can do > is to simply rename them to mbs*_l. We are lucky that all Microsoft functions > in mbsting.h are prefixed > with an underscore (e.g. _mbschr) so there should be no issues with declaring > them. So `mbs*` would conflict with gnulib. It makes much sense to provide `_mbs*` instead. > Another issue I have actually run into with str* is that tests for these > functions started to failing at > some point since gcc and clang were replacing them with built-in variants, so > I had to add -fno-builtin > (/Oi- for clang-cl.exe) when building tests. `-fno-builtin` is generally required when building the CRT. It may also be necessary to prevent involving the installed CRT, by passing `-nostdinc -nodefaultlibs`. -- Best regards, LIU Hao _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
