[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()?