Hello, Information in msvcr*def(.in) and ucrtbase*.def(.in) files should be correct. I was fixing them for all those def files and now I'm taking mingw-w64 msvcr def files as a reference information where I'm looking when I need to know if some symbol is present or not, or in which version was added (in case there are more version of e.g. msvcrt20.dll library).
So if you see something in msvcr80d.def but not in msvcr80.def then it should be correct. For your specific question about _mbsdup_dbg symbol, now I looked into msvcr80.dll library and yes, the symbol is present in msvcr80d.dll library. It does not make sense, but it is reality. Debug version of msvcrt/ucrt has one good feature which I have already used and I think can be useful for mingw-w64. It provides ability for checking memory leaks and figuring out where it happens. Recently I sent a patch which (like msvc header files) based on _DEBUG macro redirects regular calls to _dbg calls which fills file and line numbers for memory leak detector. msvcr80d.dll is probably not very interesting, but msvcrtd.dll or ucrtbased.dll can be. It is not for production using just for local debugging. About the crtdll.def, that file should be up-to-date too, but do not contain all information for symbols added in later versions. Now when you are asking about crtdll.def, I'm planning to update the documentation so in def file would be everything, like it is in msvcrt.def.in file. About the _mbscat_l() function, it exists in msvc header files and msvc compiler recognize it, see: https://godbolt.org/z/Yn697xb6h So I'm not sure if mingw-w64 should remove it. But we do not have an import library for it. I'm letting this question open. About the "#if __MSVCRT_VERSION__ >= 0x0200" and similar guards in mingw-w64 header files, I'm quite sceptical if it provides some value. For those older CRT library versions, I'm trying to do opposite direction and rather to remove such guards to make API and ABI of compiled object files more stable and more CRT neutral/agnostic. If somebody want to use _getmbcp() and is compiling for msvcrt10.dll then it really does not make difference if the error would be triggered by compiler or linker. In both cases the DLL library or EXE file would not be produced. And I'm personally think that less number of #if keywords in header file make header file more readable. So personally, I would add _ismbbblank and _ismbcblank in PATCH 5/7 without those ifdef guards too. But that is just my opinion. Remaining of patches (which are PATCH 2/7 and PATCH 6/7) are fine. Pali On Friday 07 November 2025 09:38:01 Kirill Makurin wrote: > This patch series adds some missing stuff from mbctype.h and mbstring.h, as > well as adding guards for functions which are not available in specific CRTs. > > About patch 3: I was relying on information in crtdll.def.in. Pali, feel free > to double check it. > > About patch 4: while _mbsnlen and _mbstrnlen were added in msvcr80.dll, they > are available in some OS versions of msvcrt.dll. I'm not sure if we should > expose them for msvcrt.dll. They are very Microsoft-specific and I don't > think that not exposing them is an issue. > > (At first, I got a little confused thinking that _mbstr[n]len are declared in > mbstring.h and take `unsigned char *` arguments. I thought they were missing > from mingw-w64 headers until I saw CI failure on my fork). > > About patch 7: In theory, we could provide replacements, but I see very > little if no value in doing so. > > I'm a little confused about _mbsdup[1] function. It seems like this function > was available in older CRTs, but removed in msvcr80.dll. I have list of > symbols exported from various CRTs obtained from calling `dumpbin -exports`, > and msvcr{80-120}.dll do not export it, our *.def.in files also agree with > that. However, this function is available in UCRT. > > Even more, I see that our msvcr80d.def.in exports _mbsdup_dbg and I'm > confused. Pali, do you have a way to check whether _mbsdup_dbg is really > present in msvcr80d.dll? I don't think it really matters, since I doubt > anyone would really need to use debug versions of old CRTs (well, except > crazy people like us), but I'm curious. > > I pushed this series to my GitHub fork to run CI tests[2]. > > - Kirill Makurin > > [1] > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strdup-wcsdup-mbsdup > [2] https://github.com/maiddaisuki/mingw-w64/actions/runs/19163768760 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
