On Tuesday 11 January 2022 11:40:45 Martin Storsjö wrote:
> On Mon, 10 Jan 2022, LIU Hao wrote:
> 
> > 在 2022-01-01 05:54, Pali Rohár 写道:
> > > 
> > > Well, if you want from me any improvements in this patch, I can do it.
> > > Just let me know what is needed to fix/change.
> > > 
> > > > However, cleaning the code from such workarounds seems tempting.
> > > > I wonder if
> > > > there is a real use case for this or is it just an experiment for fun?
> > > 
> > > There is a real use case to allow writing new DLL plugins with modern
> > > mingw-w64 tools for older applications which were compiled with VC6 (and
> > > which use VC6 msvcrt.dll).
> > > 
> > 
> > Jacek, do we accept this patch, or suggest a `_vscprintf` in
> > 'libmsvcrt.a' which overrides the one from MSVCRT (and provides it if
> > MSVCRT doesn't, so it's always available)? The latter seems better.
> 
> I guess that could be a nicer way of handling it, so it doesn't only help in
> this particular case, but for any caller that happens to call that function.

So, should I change my patch to do this?

> But even if this current file is built as part of libmingwex.a, the function
> __ms_vsnprintf is only called in msvcrt builds anyway, so if kept here, it
> doesn't bother UCRT anyway.
> 
> // Martin


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

Reply via email to