similar to: [PATCH] flac version of (v)snprintf

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 compile flac on say Win7 using

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

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 so very little about Windows. However, if you compile

Janne Hyv?rinen wrote: > Sorry for spamming but I noticed one more display glitch while doing > further testing. It could leave old status messages at the end of the > line while printing status messages if initial status fit on one line > and new status text required new line. Patches applied. Thanks! Erik --

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their ansi filenames and functions to utf-8. >>> >>>> Version 2 of my patch attached, which fixes

Janne Hyv?rinen wrote: > Patch v2, now handles more malformed cases. Original patch was for a > file for which I had a sample from a user but this allows handling some > manually broken test cases. Err, I'm getting warning messages on that patch: CC metadata_iterators.lo metadata_iterators.c: In function ?read_metadata_block_data_vorbis_comment_cb_?:

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 =

> OK, attempting one more convergence on all this, here's > what I did: > > 1. Reverted back to rev 1.5 of src/libFLAC/ia32/Makefile.am > 2. Applied Matt's last cleanup patch of 8 files. I did not > apply the patch to src/test_unit/main.c since it looks wrong. > main.c is supposed to include the local bitbuffer.h, not > src/libFLAC/private/bitbuffer.h; I think the

Erik de Castro Lopo wrote: >> vsnprintf (MSVC, MinGW): >> >> buf_size = 8; ret = -1; buffer = "01234567ijklmnopqrstuvwxyz" >> buf_size = 9; ret = -1; buffer = "012345678jklmnopqrstuvwxyz" >> buf_size = 10; ret = 10; buffer = "0123456789klmnopqrstuvwxyz" >> buf_size = 11; ret

Here's a patch to allow flac and metaflac handle files with malformed vorbiscomment metadata block. -------------- next part -------------- diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index d50df39..39cb276 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -78,7 +78,7 @@ static FLAC__Metadata_SimpleIteratorStatus

JonY wrote: > On 3/17/2013 23:01, LRN wrote: > >> All those ifdefs will at least be confined rather than spread out > >> through the code. > > I did it plibc-style: > > > > in compat.h: > > #if defined(_WIN32) > > #define FOPEN grabbag__fopen_utf8_wrapper > > #else > > #define FOPEN fopen > > #endif > > > > in

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan

checking whether snprintf correctly terminates long strings... no configure: WARNING: ****** Your snprintf() function is broken, complain to your vendor configure:10176: checking whether snprintf correctly terminates long strings conftest.c:181:2: error: implicit declaration of function 'exit' the test (and others) use exit without including <stdlib.h> this is a list of other

Hello, I've managed to get around the undefined paths in openssh-1.2pre14 on solaris, but now I'm stuck without an implementation of snprintf and vsnprintf. Is there a library I can download or a way to #define the functions into compatibility? Thanks, --Henry

I found that inet_ntop.c was depending on the return value of sprintf to return an int, but on SunOS4 it returns a char *. Snprintf is preferred anyway, so here's a patch to change the calls to use snprintf. Applies cleanly to the current CVS, and it was the only patch I need to apply to get 2.9p1 to build on SunOS4.1.4. On the other hand, I can't see any where inet_ntop is called, and

On (Fri) 08 May 2015 [09:19:02], Dan Carpenter wrote: > My static checker complains that this sprintf() can overflow. > > vdev->index is selected by ida_simple_get() in register_virtio_device() > so my reading of the code is that this overflow is theoretically > possible. The max value of "id" is configurable and I'm not sure what > typical values are.

>From Michele Cawley problem: tring to install on a HPUX v11 system. make install comming back with below error. Using LIBS = -lgen -lsec -lnsl Compiling lib/snprintf.c lib/snprintf.c:792: conflicting types for `snprintf' /usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.1/include/stdio.h:493: previous d eclaration of `snprintf' *** Error exit code 1 Stop. regards Michele

Hello, I used the snprintf.{c,h} in rsync for my code, and found a bug in it: snprintf(s,16,"%f",0.025) results "0.250000". The problem is in snprintf.c, in fmtfp(), around line 732. I didn't try the solution (I do not need it anymore), but the zpadding number of '0'-s should be placed before fconvert. I am not in the list, so please cc the answer for the

https://bugzilla.samba.org/show_bug.cgi?id=8294 Summary: lib/snprintf.c compile fix Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: chris at onthe.net.au QAContact:

https://bugzilla.samba.org/show_bug.cgi?id=11229 Bug ID: 11229 Summary: off-by-one in snprintf() check Product: rsync Version: 3.1.1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter: sbehrens at