在 2020/2/23 6:06, Martin Storsjö 写道: > On Thu, 20 Feb 2020, Pali Rohár wrote: > > While they are "wrong" in that sense, this now means that there is no > symbol "snprintf" defined at all, which does break compilation of a > number of projects. (That primarily happens within configure scripts of > certain projects, that try to detect if "snprintf" exists, without > including stdio.h.) In all sane cases, the calling code that includes > stdio.h will end up calling __ms_snprintf anyway, where you get your fix. > > So while this change is well-intended, it is also a bit too heavy > handed, as there's many aspects to take into account with keeping as > much software compiling while striving for good standards compliance. > > So either I'd suggest reintroducing these again (reverting this bit of > the patch), or making "snprintf" available as an alias for > "__ms_snprintf". I can try making a patch for this, within a few days. >
MSVCR* DLLs don't have `snprintf()`, and its behavior is different from `sprintf()`. I agree with the latter (making `snprintf()` a conditional alias). > > Here you're reusing argptr again, after already using it once for > _vsnprintf > above. I think the correct solution to that is to make a new va_arg with > va_copy, before calling _vsnprintf. > > // Martin > Although it is not good practice, there has already been some code written that way (such as in 'asprintf.c'). I thought about this a little: The purpose of `va_copy()` is that `va_list` might be an array type (like `jmp_buf`), but this isn't the case. It is `char*` for mingw-w64 so should be safe to copy. Another problem is that `va_copy` was only introduced by C99. There was no way t -- Best regards, LH_Mouse
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
