While it is mkdtemp in this specific case for busybox-w32, the fact that 
mingw-w64 provides [POSIX/GNU] functions beyond CRT may cause similar issues in 
other packages. The one that usually comes to mind for me is gnulib.

Things get even more complicated if the function in question is either defined 
inline or uses assembly for redirection (such as functions which depend on size 
of off_t and time_t). I ran into issues with str[n]casecmp functions in my 
posix32 library; mingw-w64's string.h could define them as inline wrappers 
around _str[n]icmp. In this case I could not be sure whether compiler was 
generating inlined call to _str[n]icmp or external call to library's 
str[n]casecmp. Needless to say that library's str[n]casecmp are not simply 
wrappers around CRT's _str[n]icmp, so this was really undesired.

I'm still not sure how to handle functions which use assembly for redirection. 
Also, in case of MSVC, these are usually static wrappers which call explicitly 
sized versions or macros (e.g. in case of stat functions). But these are 
problems for future me.

It would be nice if we could come up with some way to deal with these issues. I 
was thinking maybe some feature macro could be added, which when defined, would 
prevent such functions from being exposed?

- Kirill Makurin
________________________________
From: Pali Rohár <[email protected]>
Sent: Sunday, January 18, 2026 7:00 AM
To: Martin Storsjö <[email protected]>
Cc: [email protected] 
<[email protected]>
Subject: Re: [Mingw-w64-public] [PATCH] crt: Implement POSIX mkdtemp() function

On Saturday 17 January 2026 15:03:31 Martin Storsjö wrote:
> On Fri, 16 Jan 2026, LIU Hao wrote:
>
> > 在 2025-12-20 00:24, Pali Rohár 写道:
> > > POSIX mkdtemp() function creates a unique temporary directory from input
> > > template string.
> > >
> > > Implementation is copied from mingw-w64-crt/misc/mkstemp.c file with
> > > replaced _sopen() call by the _mkdir() call.
> > > ---
> > >   mingw-w64-crt/Makefile.am      |  3 +-
> > >   mingw-w64-crt/misc/mkdtemp.c   | 83 ++++++++++++++++++++++++++++++++++
> > >   mingw-w64-headers/crt/stdlib.h |  1 +
> > >   3 files changed, 86 insertions(+), 1 deletion(-)
> > >   create mode 100644 mingw-w64-crt/misc/mkdtemp.c
> > >
> > > diff --git a/mingw-w64-headers/crt/stdlib.h
> > > b/mingw-w64-headers/crt/stdlib.h
> > > index a53c2ecb1c51..23c653d186f6 100644
> > > --- a/mingw-w64-headers/crt/stdlib.h
> > > +++ b/mingw-w64-headers/crt/stdlib.h
> > > @@ -355,6 +355,7 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void);
> > >     size_t __cdecl mbstowcs(wchar_t * __restrict__ _Dest,const char
> > > * __restrict__ _Source,size_t _MaxCount);
> > >     _CRTIMP size_t __cdecl _mbstowcs_l(wchar_t * __restrict__
> > > _Dest,const char * __restrict__ _Source,size_t _MaxCount,_locale_t
> > > _Locale);
> > >     int __cdecl mkstemp(char *template_name);
> > > +  char *__cdecl mkdtemp(char *template_name);
> >
> > The name of this parameter has to be uglified. I will do that in a
> > separate commit.
> >
> > Other than that, this patch looks good to me. Pushed now.
>
> FYI, this patch broken compilation of busybox-w32 - with error messages like
> this:
>
> In file included from
> /home/runner/work/llvm-mingw/llvm-mingw/busybox-w32/applets/applets.c:9:
> In file included from
> /home/runner/work/llvm-mingw/llvm-mingw/busybox-w32/include/busybox.h:8:
> In file included from
> /home/runner/work/llvm-mingw/llvm-mingw/busybox-w32/include/libbb.h:38:
> /opt/llvm-mingw/i686-w64-mingw32/include/stdlib.h:358:17: error: function
> declared 'cdecl' here was previously declared 'stdcall'
>   358 |   char *__cdecl mkdtemp(char *_TemplateName);
>       |                 ^
> /home/runner/work/llvm-mingw/llvm-mingw/busybox-w32/include/platform.h:615:14:
> note: previous declaration is here
>   615 | extern char *mkdtemp(char *template) FAST_FUNC;
>       |              ^
> 1 error generated.
>
> I ran into this in my nightly build of llvm-mingw, where I recently included
> busybox-w32 among the tools I build and bundle: 
> https://github.com/mstorsjo/llvm-mingw/actions/runs/21085840201/job/60657330345
>
> I reported this issue to busybox-w32 at
> https://github.com/rmyorston/busybox-w32/issues/555.
>
> This looks mostly like an issue that should be fixed on the busybox-w32
> side, but ideally we should coordinate with them around a fix for the issue.
> (In the worst case, we could consider temporarily reverting this addition
> here until it is sorted out on the busybox-w32 side. I'm unable to include
> newer versions of mingw-w64 in releases of llvm-mingw until this is sorted
> out...)
>
> // Martin

Breaking application in such way is not good.

If I understand correctly from the error message, the problem is not
that mingw-w64 provides mkdtemp symbol, but rather the fact that
mingw-w64 provides function declaration with cdecl calling convention
but busybox expects the stdcall one.

I'm not sure how was stdcall chosen, maybe by that FAST_FUNC macro?

As a fix for busybox, maybe could help if busybox is able to change
calling convention of their mkdtemp from stdcall to cdecl? Compiler then
should not complain about that discrepancy between the calling
convention. And the linker should not take the mkdtemp symbol from
static libmingwex.a archive as the provided by busybox would be probably
forced.

But the proper fix should be to have some autodetection in busybox if
the mkdtemp symbol is available. I see that in reported issue there was
an idea to call 'int main(void) { return !mkdtemp("foo"); }' at build
time to detect if the symbol is present.

This code could be improved to 'int main(void) { return !&mkdtemp; }'
which would not call the mkdtemp function but still fails compilation
if the function symbol is not available at the include OR link time.

If it does not help then we would have to revert that change. Or maybe
providing the function under different name. For example mingw_mkdtemp?


_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to