[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crash in 'find_and_set_default_shell()'

From: Paul Smith
Subject: Re: Crash in 'find_and_set_default_shell()'
Date: Sun, 19 Jun 2022 09:23:41 -0400
User-agent: Evolution 3.44.1 (by Flathub.org))

On Sun, 2022-06-19 at 08:47 +0300, Eli Zaretskii wrote:
> > I do have a memory that some versions of Visual Studio, up until
> > relatively recently, have non-standard implementations of
> > snprintf()
> > but hopefully it's standard enough to manage this.
> If we now rely on ANSI-standard behavior of snprintf in the Windows
> port, we need the MinGW build to use -D__USE_MINGW_ANSI_STDIO=1, to
> force replacement of the MS version of snprintf with MinGW's own
> reimplementation, which is ANSI-standard.  That's because linking
> Make against MSVCRT.DLL will use a non-compliant snprintf in that DLL
> (MinGW cannot link against proprietary C runtime libraries that come
> with later versions of Visual Studio).

As best as I recall, the non-standard part of the old snprintf() was
that it returned -1 if the buffer wasn't large enough, rather than the
number of chars that would be needed.

The change made here doesn't rely on that behaviour.

However I realize now that I need to forcibly add a nul terminator
because the old snprintf() on Windows didn't nul-terminate the string
if the buffer wasn't large enough.

Maybe I'll just punt on that and simply allocate a large-enough buffer.

Were there other differences in old snprintf()?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]