similar to: [PATCH] for test_streams

test_streams currently depends on grabbag and (on Windows) on win_utf8_io libs. It depends on win_utf8_io only because it uses flac_fopen() function. It will become to depend on libFLAC when all file functions will be moved from win_utf8_io to libFLAC. Not a big problem, but it is possible to avoid this dependency by replacing flac_fopen() with fopen(). test_streams doesn't open/create

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if

test_streams doesn't create/open files with non-ascii filenames, so there's no need in unicode support. The patch changes flac_fopen() calls to fopen(), and removes dependency of test_streams from win_utf8_io. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_streams.zip Type: application/zip Size: 2445 bytes Desc: not available Url :

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_vsnprintf instead of vsnprintf. Return value checking becomes

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 =

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

Analogous to M_LN2 patch: the patch moves definition of M_PI from src/libFLAC/window.c and src/test_streams/main.c to include/share/compat.h -------------- next part -------------- A non-text attachment was scrubbed... Name: M_PI.patch Type: application/octet-stream Size: 1581 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130925/6a0afebe/attachment.obj

Hi all, I've been notified of a CVE to be publish against FLAC early next week. I have a patch for it and have thoroughly tested it as well as had it verified by the Google Security Team member who found it. I've been asked not to publish that patch until Tuesday. Once I publis the patch, I like to release FLAC 1.3.1 immediately and would therefore like to make sure that all the

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

That enables an special implementation that checks for common memory errors and will save us from a lot pain. --- test/test_bins.sh | 2 ++ test/test_flac.sh | 2 ++ test/test_grabbag.sh | 2 ++ test/test_libFLAC++.sh | 2 ++ test/test_libFLAC.sh | 3 +++ test/test_metaflac.sh | 2 ++ test/test_seeking.sh | 2 ++ test/test_streams.sh | 2 ++ 8 files

My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). You could simply have the following: #if defined _MSC_VER || defined __MINGW32__ #define flac_fopen fopen #endif In a header, or simply at

Hi all, As people may have seen there's a pre-release here: http://downloads.xiph.org/releases/flac/beta/ Specifically: flac-1.3.1pre1.tar.xz : The source code flac-1.3.1pre1-win.zip : Windows 32 and 64 bit binaries Please test. I'm particularly interested in hearing about the windows binaries which were cross compiled from Linux to Windows. Unfortunately there is a bug

Ah, ok. I was thinking along the lines of FLAC__int32, where the intention is to be portable without depending upon any specific system. I assumed that flac_fopen() came from that design pattern. If it's really only a few years old, and not original, then changing it back should be fine. A bigger question might be: how are file opens handled in most flac code? It's probably best for

make fullcheck fails on my computer: flac cannot recognize --skip option that contains decimal point, e.g. "--skip=1.234". System locale uses comma as a separator, so strtod/atof expect comma, not point, and "make fullcheck" fails. Here's what I can see in FLAC source code: atof() function found in: file: src/share/grabbag/seektable.c function:

Seems time is going to be a constraint for me in the coming week, but I'll try and get more of these out to you as fast as I can get them written and tested. Keeping the patches in a separate branch for now seems like a good idea to me. Attached is a patch for 'test_streams.sh' On Tue, Mar 12, 2013 at 1:44 AM, Erik de Castro Lopo <mle+la at mega-nerd.com>wrote: > Jaren

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

Thanks, Erik. This is the delta that should fix everything up. I hope that #include "share/compat.h" is acceptable from the test_streams binary. If not, you can probably change it to FLAC/ordinals.h instead Also don't forget to commit my earlier VERSION="1.3.0" patch. You can add the "pre1" in a normal text editor without risk. I didn't include those

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

Those checks account for compiler changes/improvements introduced in Visual Studio 2010 that are not present in Visual Studio 2008. I will grab Visual Studio 2012 off of MSDN and make sure everything is OK there. -Ben > Hi Ben, > > Can you please remove the _MSC_VER >= 1600 check? > > _MSC_VER 1600 is set for Visual Studio 2010, which means > that Visual Studio 2012 will

Hi all, For testing a few mingw-builds I tried to use ./configure --disable-thorough-testing (because testing in a virtual machine through mingw isn't really fast) but it turned out this setting doesn't do anything. It turns out these configuration options aren't passed to the test scripts at all. I do not fully understand how Makefiles or environment variables work, but my