search for: vsnprintf_

On 9/21/2014 06:58, lvqcl wrote: > Erik de Castro Lopo wrote: > >>> MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib >>> or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible >>> with WinXP. So it is safe to use it in FLAC. >> >> Oh, ok. I missed this bit. I know so very little about Windows. >> &...

lvqcl wrote: > Oops. It seems that vsnprintf_s isn't always available on MinGW platform: > MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. > That's because WinXP version of msvcrt.dll doesn't contain secure functions > like vsnprintf_s. > > Maybe it's better to revert vsnprintf_s to v...

lvqcl wrote: > I wrote a small program that fills a buffer[] with "abcdefghijklmnopqrstuvwxyz\0" > pattern and then tries to write "0123456789" string into it. > It calls either > ret = vsnprintf_s(buffer, buf_size, _TRUNCATE, fmt, va); > or > ret = vsnprintf(buffer, buf_size, fmt, va); <snip> > vsnprintf (MSVC, MinGW): > > buf_size = 8; ret = -1; buffer = "01234567ijklmnopqrstuvwxyz" > buf_size = 9; ret = -1; buffer = &...

lvqcl wrote: > Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. > > MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib > or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible > with WinXP. So it is safe to use it in FLAC. Oh, ok. I missed this bit. I know...

...ret = 10; buffer = "0123456789klmnopqrstuvwxyz" >> buf_size = 11; ret = 10; buffer = "0123456789" >> buf_size = 12; ret = 10; buffer = "0123456789" > > This is actually the only one we can use. Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible with WinXP. So it is safe to use it in FLAC. OTOH MinGW uses vsnprintf_s from msvcrt.dll file that...

Erik de Castro Lopo wrote: >> Oops. It seems that vsnprintf_s isn't always available on MinGW platform: >> MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. >> That's because WinXP version of msvcrt.dll doesn't contain secure functions >> like vsnprintf_s. >> >> Maybe it's better to reve...

Janne Hyv?rinen wrote: > Some comments for patch #1, I chose the non-secure versions because they > are faster and produce smaller binary. The functions where these > printings are performed can't in my opinion ever exceed the safety > margin of 32 KB. They print short help and error texts and occasionally > filename, which with APIs is restricted to 260 characters. And you

...gt; but they are nowhere near the speed critical parts of the FLAC code. > They also *document* the fact that they are safe so you really only > need to look where they are called rather than thinking about maximum > command line lengths and maximum file name lengths. Oops. It seems that vsnprintf_s isn't always available on MinGW platform: MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. That's because WinXP version of msvcrt.dll doesn't contain secure functions like vsnprintf_s. Maybe it's better to revert vsnprintf_s to vsprintf or to use vnsprin...

lvqcl wrote: > Oops. It seems that vsnprintf_s isn't always available on MinGW platform: > MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. > That's because WinXP version of msvcrt.dll doesn't contain secure functions > like vsnprintf_s. I thought Micorsoft had recently stopped supporting WinXP....

JonY wrote: > You could just request mingw to include a vsnprintf_s implementation for > XP and earlier, mingw-w64 has already done so. I use MinGW-w64: it's XhmikosR's MSYS that contains "MinGW-w64 build of GCC/Binutils for Windows" from nevcairiel. It has mingw-w64 3.1.0 inside. But I thought that MinGW-w64 links with msvcrt.dll and uses v...

Erik de Castro Lopo wrote: >> MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib >> or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible >> with WinXP. So it is safe to use it in FLAC. > > Oh, ok. I missed this bit. I know so very little about Windows. > > However, if you...

Declan Kelly wrote: > On Thu, Sep 18, 2014 at 07:53:12PM +1000, mle+la at mega-nerd.com wrote: > > > I thought Micorsoft had recently stopped supporting WinXP. > > Apparently they changed their mind, due to a large number of users not > upgrading. Security updates, including a monthly malware detection tool, > are still released for XP on Windows Update. <sigh>

For better readability the patch is divided by 3 parts. Part #1: for a bit better security replace vsprintf(utmp, format, argptr) with vsnprintf_s(utmp, 32768, _TRUNCATE, format, argptr) Part #2: potential memleak fixed: utf8argv[i] are not freed when utf8argv itself is freed. Part #3: 'if (ret != 0) break;' line seems redundant. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_io.zip T...

...conversions are discarded if something failed so not exiting from the loop is wasted effort. On 8.8.2014 18:18, lvqcl wrote: > For better readability the patch is divided by 3 parts. > > Part #1: for a bit better security replace > vsprintf(utmp, format, argptr) > with > vsnprintf_s(utmp, 32768, _TRUNCATE, format, argptr) > > > Part #2: potential memleak fixed: utf8argv[i] are not freed > when utf8argv itself is freed. > > > Part #3: 'if (ret != 0) break;' line seems redundant. > > > _______________________________________________ > fl...

Hi On MSVCRT, wprintf expects that %s is wide char string, but for not MSVCRT, this is not true. When using -D__USE_MINGW_ANSI_STDIO=1 on MINGW, mingw doesn't use MSVCRT. Therefore, compiling on mingw with -D__USE_MINGW_ANSI_STDIO=1 and redirecting stderr to a file, the printing result is corrupt. We should use fputws simply. A patch is attached. -------------- next part