We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

I've implemented a work-around by adding a memset that calls SDL_memset (See the patch to SDL_string in https://github.com/bincrafters/conan-sdl2/pull/25). No idea what generates the implicit memset here - does not seem to be one of the ordinary array-inits.

Hello,

I recently became affected by this bug after updating to the latest Visual Studio 2019 (16.2.3.)  I'm building SDL2 as a dependency in a CMake project, and the bug occurs when I build on Windows 10 (10.0.17763 Build 17763) with -DCMAKE_BUILD_TYPE=Release using VS2019 (MSVC 19.22.27905.0).

I was able to build successfully using these parameters in the previous version of VS2019, so my suspicion is that this is a Microsoft implementation issue.

Thanks for filing.

I've filed a bug report in Visual Studio using the title "Unexpected implicit memset in release-optimized build causes LNK2019 in VS2019 16.2.3" if anyone cares to upvote it.

your log says it's in 


SDL_string.c.obj : error LNK2019: unresolved external symbol memset referenced in function SDL_vsnprintf_REAL


look at the file:
src/stdlib/SDL_string.c
see which SDL_vsnprintf gets compiled.

find out which line adds an implicit memset ...

So the usual things that encourage Visual Studio to generate a memset call (a loop that initializes all elements of an array to zero, a local array with an explicit initializer) aren't present in SDL_vsnprintf(). Can you attach SDL_string.c.obj to this report so I can see what the new Visual Studio did?

Thanks,
--ryan.

(In reply to Ryan C. Gordon from comment #5)
> So the usual things that encourage Visual Studio to generate a memset call
> (a loop that initializes all elements of an array to zero, a local array
> with an explicit initializer) aren't present in SDL_vsnprintf().

Actually, I was looking at the wrong #ifdef, there are a few possible suspects, like this:


        while (len--) {
            if (textstart+len < end) {
                textstart[len] = fill;
            }
        }


...where the compiler might have gotten smart enough to slot a memset in place of that loop. Send in the .obj and I'll look at it.

--ryan.

Actually, why don't we turn that into an SDL_memset()?

(In reply to Sam Lantinga from comment #7)
> Actually, why don't we turn that into an SDL_memset()?

We can, I just don't want to play whack-a-mole if it turns out there's three other places that need this, which is why I wanted the .obj file.   :)

--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

Hearing nothing, I replaced some possible culprits in https://hg.libsdl.org/SDL/rev/3def438a1540 but I don't know if I actually got it.

It's worth noting that there are a ton of loops in this file that are just as likely to get replaced with a memset() or memcpy()...they're in SDL_memset and SDL_memcpy, of course.

I'm wondering if we should just implement a few of these standard functions when #ifdef _MSC_VER and not export them outside the DLL, so the next time Visual Studio inserts a memset() call, it resolves to inside SDL, and nothing external see is. There are probably a million ways this can go wrong, though.

For now, I'm closing this bug. If the problem still persists, please reopen.

--ryan.