Displaying 20 results from an estimated 20000 matches similar to: "[PATCH] for grabbag/snprintf.c"
2014 Sep 21
2
[PATCH] flac version of (v)snprintf
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
2016 Jan 29
2
Lets do a 1.3.2 release
Erik de Castro Lopo wrote:
>> Currently functions in win_utf8_io.c are a compatibility layer for
>> libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC.
>
> Ok, lets do it.
I just thought that it's more complicated. All *file* functions should
really be moved to libFLAC. But other functions should not, because
libFLAC doesn't use them.
Two of them -
2013 Mar 14
4
snprintf and MS Visual Studio
Hi all,
There are a bunch of sprintf calls in the FLAC code base and I'd like
to replace them with calls to snprintf but I know that can cause
problems with at least some versions of Visual Studio.
Whats the current state of play in this regard?
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
2014 May 30
3
Typos in the FLAC codebase
1) src/share/grabbag/snprintf.c, line 42: 'on systems with a norrmal ISO C99'
'norrmal' -> 'normal'
2) src/flac/encode.c, line 1661: '(eg, very short files, < 10000 fames)'
'fames' -> frames? samples? bytes?
3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)'
Not sure about this, but
2016 Dec 07
5
Do we need a pre-release?
Erik de Castro Lopo wrote:
> Unfortunately I've lost/forgotten my Xiph SVN password. While I get
> that sorted out for the real release, the pre-releases are here:
>
> http://mega-nerd.com/tmp/flac-1.3.2pre1-win.zip
> http://mega-nerd.com/tmp/flac-1.3.2pre1.tar.xz
Forgot to mention that I have tested this on x86_64/linux, armhf/linux
and powerpc/linux.
Erik
--
2016 Jan 28
2
Lets do a 1.3.2 release
lvqcl wrote:
> all I can suggest
> is to apply this patch, then fix issues if they'll happen after
> this.
But seriously, as a matter of fact win_utf8_io is a part of libFLAC.
Functions from libFLAC call functions from win_utf8_io...
For example: FLAC__stream_decoder_init_file() calls init_file_internal_()
that calls flac_fopen() that is defined as fopen_utf8().
Currently
2016 Jun 26
4
FLAC__SSE_OS change
lvqcl wrote:
> It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails.
> It can be fixed by adding "#include share/compat.h" to cpu.c (or by using
> FLAC__uint32 from FLAC/ordinals.h).
Ok, added share/compat.h.
> When I fix this, the following problem occurs:
>
> error LNK2019: unresolved external symbol ___cpuidex referenced in
2013 Sep 08
7
PATCH: x86-64 support and SSE intrinscis code
It's not possible to use ia32/*.nasm code in 64-bit compiles.
There's still no 64-bit asm code in FLAC. I'm not familiar with asm too,
so I wrote SSE-accelerated code using intrinsics.
This code uses two new preprocessor macros:
FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32)
and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM)
Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3)
2014 Sep 18
3
patch for win_utf8_io.c: vsnprintf_s vs. MinGW
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
2013 Mar 15
2
snprintf and MS Visual Studio
Christoph Terasa wrote:
> Since MS refuses to support C99, the common practice is to use either
>
> sprintf_s:
> http://msdn.microsoft.com/en-us/library/ce3zzk1k(v=VS.80).aspx
> _snprintf_s:
> http://msdn.microsoft.com/de-de/library/f30dzcf6(v=VS.80).aspx
>
> The former can be used as a drop-in replacement of snprintf via a
> define, the latter takes an
2014 Sep 20
2
vsnprintf_s and vsnprintf
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 =
2016 Mar 09
2
Broken build on musl libc
Patch is here: https://github.com/openwrt/packages/commit/1263599f96f13f11d719ce336dfb6a639b32de98 . Probably needs to be modified for inclusion into mainline.
2014 Jun 27
4
Lets work towards a new version
Martijn van Beurden wrote:
> Like I reported just before the release of 1.3.0 (mail of Fri,
> 05 Apr 2013 08:25:10 +0200, to be specific), compiling on
> Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of
> the type -Wcast-align.
>
> > CC lpc_intrin_sse2.lo
> > CC lpc_intrin_sse41.lo
> > CC md5.lo
> > md5.c: In function
2015 Dec 28
6
How to check for 64-bit CPU?
In stream_encoder.c there's the following code:
#if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */
if(mean <= 0x80000000/512) { /* 512: more or less optimal for both 16- and 24-bit input */
#else
if(mean <= 0x80000000/8) { /* 32-bit arch: use 32-bit math if possible */
#endif
A) How to properly check for 64-bit architectures?
I can check for "defined
2014 Jul 09
3
[PATCH] PPC/Altivec removal
This set of patches removes PPC/Altivec code from FLAC.
I decided to split the patch into 5 parts to make it
more simple:
1) removes FLAC__lpc_restore_signal_asm_ppc_altivec_16*
from lpc.h and stream_decoder.c
2) removes PPC-specific code from cpu.c and cpu.h
3) removes PPC stuff from libFLAC/Makefile.lite and build/*.mk
4) removes as/gas/PPC-specific stuff from configure.ac
and
2017 Jan 18
3
[PATCH] fix MSVC 2005/2008 build
lvqcl wrote:
> > These versions of Visual Studio don't have stdint.h and
> > all [u]intNN_t types. But now these types are everywhere
> > in FLAC codebase.
>
> Here is the patch that fixes the problem:
> it moves definitions of all [u]intNN_t types from share/compat.h
> into new file share/msvc2005_int.h and then includes this file
> into all files (via
2017 Jan 25
3
[PATCH] cpu.h: add defines for clang
Currently cpu.h lacks FLAC__SSE_TARGET and FLAC__SSEnn_SUPPORTED
macros for clang. I added them, but I cannot properly test them
as I can't get compiled flac.exe under Windows (don't know
how to setup clang under MSYS2).
If somebody has working clang, please test this patch.
Does it affect en/decoding speed?
Or at least, dows it affect disassembly of functions
such as
2014 Apr 30
2
make fullcheck fails: strtod/atof and locale
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:
2016 Dec 21
11
1.3.2pre3 (Hopefully final)
Hi all,
New pre-release here is at:
http://mega-nerd.com/tmp/flac-1.3.2pre3-win.zip
http://mega-nerd.com/tmp/flac-1.3.2pre3.tar.xz
Changes:
* Fix tests with Makefile.lite build system.
* Fixes for non-Intel CPUs.
MD5 and SHA256 sums:
> md5sum flac-1.3.2pre3*
61aa8597a220303daf4beb2b8756979d flac-1.3.2pre3.tar.xz
8b470ceac02340600db73bc6daea4fc7 flac-1.3.2pre3-win.zip
2016 Feb 08
2
[PATCH] remove libFLAC dependency of win_utf8_io
Erik de Castro Lopo wrote:
> lvqcl wrote:
>
>> The set of four patches that remove dependency of libFLAC on win_utf8_io.
>>
>> Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and makefile.lite)
>>
>> Please review, especially makefile patches, I'm not very familiar with them.
>
> Applied. All good. Thanks.
But the 1st patch