Re: MSVC: Improve warning options set

Hi,

On 2025-11-03 19:56:16 +0100, Peter Eisentraut wrote:
> I don't know if we still support MSVCRT if using MSVC, or how long we still
> need to support it. (Or, for example, how to tell which variant CI or the
> buildfarm uses.)

To my knowledge anything close to a recent version visual studio / msvc don't
use msvcrt anymore. Starting at least with VS 2015. I don't think our code
would really work when building against msvcrt anyway (mingw worked for
longer, because they added additional functionality in wrapper libraries,
IIRC).

> > static const char *const modulenames[] = {
> >         "msvcrt",                /* Visual Studio 6.0 / MinGW */
> >         "msvcrtd",
> >         "msvcr70",                /* Visual Studio 2002 */
> >         "msvcr70d",
> >         "msvcr71",                /* Visual Studio 2003 */
> >         "msvcr71d",
> >         "msvcr80",                /* Visual Studio 2005 */
> >         "msvcr80d",
> >         "msvcr90",                /* Visual Studio 2008 */
> >         "msvcr90d",
> >         "msvcr100",                /* Visual Studio 2010 */
> >         "msvcr100d",
> >         "msvcr110",                /* Visual Studio 2012 */
> >         "msvcr110d",
> >         "msvcr120",                /* Visual Studio 2013 */
> >         "msvcr120d",
> >         "ucrtbase",                /* Visual Studio 2015 and later */
> >         "ucrtbased",
> >         NULL
> >     };
>
> So that would mean we can remove all but the two ucrt* entries? Is there no
> more msvcr* after VS 2015?

Correct, there's no msvcrt*dll anymore for anything recent. I think there's
still link libraries named like similarly, but that shouldn't matter here.
However - that doesn't necessarily mean that no msvcrt could be loaded into
the same process, e.g. when linking against an older library that's built
against msvcrt. On windows multiple runtime libraries can exist in the same
process (which is why it's not safe to allocate/deallocate memory or
open/close files across library boundaries).

I'm not sure the gain from pruning the above list is worth the potential
subtle breakage that could result.

Greetings,

Andres Freund