Hello, I sent an update for crtdll.def.in file. Now it should contain all required information about symbol availability up-to-date.
On Friday 07 November 2025 18:25:09 Kirill Makurin wrote: > It would be too easy if things would make sense :) > > I agree that debug features available in debug versions of CRTs are useful, > especially memory allocation functions. I'm using them as well, but mostly > with MSVC. > > _mbscat_l does not seem to be exported from any msvcr*.dll I have on my > system. I checked MSVC's mbstring.h and it seems that _mbscat_l is defined as > overload template around _mbscat_s_l. It is not declared as an external > function. > > I prefer compilation errors to linker errors, but I would like to hear what > others think about it. I think both approaches are reasonable. > > - Kirill Makurin > ________________________________ > From: Pali Rohár <[email protected]> > Sent: Saturday, November 8, 2025 2:48 AM > To: Kirill Makurin <[email protected]> > Cc: mingw-w64-public <[email protected]> > Subject: Re: Fixes for mbctype.h and mbstring.h > > 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
