search for: flac_snprintf

...ntf can return positive value > even when it didn't write '\0' at the end. So > if (rc < 0) { ... str [...] = 0; } > is not enough. Like I said, untested. It was the first thing that came into my head version of the code :-). > What about this version -- > > int flac_snprintf(char *str, size_t size, const char *fmt, ...) > { > va_list va; > int rc; > > va_start (va, fmt); > > #if defined _MSC_VER > rc = vsnprintf_s (str, size, _TRUNCATE, fmt, va); > if (rc < 0) > rc = size - 1; > #elif defined __MINGW32__ && (!defined...

...irements if the ISO C specs. I'm basically think of something like the (untested) diff below. Erik diff --git a/src/share/grabbag/snprintf.c b/src/share/grabbag/snprintf.c index 3a0661f..6a4e3ea 100644 --- a/src/share/grabbag/snprintf.c +++ b/src/share/grabbag/snprintf.c @@ -62,8 +62,11 @@ flac_snprintf(char *str, size_t size, const char *fmt, ...) va_start (va, fmt); #ifdef _MSC_VER - rc = vsnprintf_s (str, size, _TRUNCATE, fmt, va); - rc = (rc > 0) ? rc : (size == 0 ? 1024 : size * 2); + rc = vsnprintf (str, size, fmt, va); + if (rc < 0) { +...

...the return value and a line or two of extra > code, this function can made to behave resonably sensibly, even it > its not possible to make it meet the requirements if the ISO C specs. > > I'm basically think of something like the (untested) diff below. > > @@ -62,8 +62,11 @@ flac_snprintf(char *str, size_t size, const char *fmt, ...) > va_start (va, fmt); > #ifdef _MSC_VER > - rc = vsnprintf_s (str, size, _TRUNCATE, fmt, va); > - rc = (rc > 0) ? rc : (size == 0 ? 1024 : size * 2); > + rc = vsnprintf (str, size, fmt, va); > + if (r...

...to the system headers and breaks mingw if > FLAC_USE_FOPEN_UTF8 is defined. > > Call the wrappers directly instead of using a macro. +1 Yep, I prefer not to have too much #ifdef hackery. In my recent replacement of all the sprintf/_snprintf stuff, I relaced all the calls with a call to flac_snprintf() and localised #ifdef hackery to the implementation of that function.

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

...the dynamically compiled binary to WinXP it will fail, right? No, flac.exe compiled with MSVS 2013 (and dynamically linked with MSVC runtime) will simply require msvcr120.dll to run. On both OSes. > Either of those two are fine. You choose and send a patch. I'll write > a unit test for flac_snprintf to capture our assumptions. I would like to know opinions of other people... Especially because I'm not very familiar with MinGW. Anyone? P.S. There are 3 places where flac uses vsnprintf: 1) flac_snprintf inside src/share/grabbag/snprintf.c 2) local_snprintf inside src/libFLAC/metadata_iter...

The patch changes flac_snprintf (in src/share/grabbag/snprintf.c) and its copy local_snprintf (src/libFLAC/metadata_iterators.c). It also adds flac_vsnprintf (src/share/grabbag/snprintf.c) and its copy local_vsnprintf (src/share/win_utf8_io/win_utf8_io.c). And it changes stats_print_info in src/flac/utils.c so it uses flac_vsnp...

src/test_streams/main.c fails under MSVC because it doesn't provide snprintf(). The patch replaces snprintf() with flac_snprintf(). -------------- next part -------------- A non-text attachment was scrubbed... Name: test_streams.patch Type: application/octet-stream Size: 486 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20150223/b0908a26/attachment.obj

...FLAC_USE_FOPEN_UTF8 is defined. > > > > Call the wrappers directly instead of using a macro. > > +1 > > Yep, I prefer not to have too much #ifdef hackery. > > In my recent replacement of all the sprintf/_snprintf stuff, I relaced all > the > calls with a call to flac_snprintf() and localised #ifdef hackery to the > implementation of that function. > > >From a patch cleanliness POV, I like to see the new functionality added in > one patch and a separate patch to change all the old function usage to the > new function usage. For example, in commit 06af23...

...saved_locale); so RG tags always have decimal point 4) flac and metaflac: main() calls setlocale(LC_ALL, "") which sets default system locale 5) Probably it's better to use local version of strtod() that accepts both comma and point as separators (just as FLAC uses local_strdup or flac_snprintf).

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17.03.2013 18:55, JonY wrote: > On 3/17/2013 18:37, Erik de Castro Lopo wrote: >> JonY wrote: >> >>> On 3/17/2013 10:33, Janne Hyv?rinen wrote: >>>> Here's a patch that makes MSVC compiled flac.exe able to use >>>> wildcards and encode/decode files with Unicode characters in >>>>

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 vsprintf or to use vnsprintf? Ok, we need to drop