similar to: Are pointers to FLAC__int32 and int interchangeable?

Erik de Castro Lopo wrote: > Well FLAC__int32 is just a 32 bit integer and on all the platforms/ > architecures/compilers that FLAC supports FLAC__int32 and int are > the same. > > Personally I think the FLAC__xxxx stuff should go, to be replaced with > C standard int32_t, uint32_t, int16_t etc, at least for internal code. > I am slowly doing that when I touch code. > >

--- src/libFLAC/bitreader.c | 445 +++++++++++------------------------------------ 1 files changed, 105 insertions(+), 340 deletions(-) diff --git a/src/libFLAC/bitreader.c b/src/libFLAC/bitreader.c index ae515a0..7ae086d 100644 --- a/src/libFLAC/bitreader.c +++ b/src/libFLAC/bitreader.c @@ -755,379 +755,144 @@ FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsig }

lvqcl wrote: > Is it Ok to pass FLAC__int32* in a function that expects int* ? Well FLAC__int32 is just a 32 bit integer and on all the platforms/ architecures/compilers that FLAC supports FLAC__int32 and int are the same. As for pointers, all pointers are the same until you try an increment them. If you have some type, lets call it sometype_t, and a pointer to types of sometype_t :

unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In function `FLAC__bitreader_read_rice_signed_block': bitreader.c:850:

Hi, attached are patches that improve decoding speed a bit. The first patch improves the bit scan macro used for decoding unary values, the second one adds a GCC inline assembly for bswap and the third patch replaces the read_rice_block function. In my testing it turned out to be even faster than the _ia32_bswap function. If the code produced by MSVC is faster as well, I'd suggest to remove

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

Hi all, I've made a test release for Ogg DirectShow Codecs. You can find it here: http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe The problem is that I get a HEAP Corruption detected at: void FLAC__bitreader_free(FLAC__BitReader *br) { FLAC__ASSERT(0 != br); if(0 != br->buffer) free(br->buffer); The call stack is: >

Hi all, I've made a test release for Ogg DirectShow Codecs. You can find it here: http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe The problem is that I get a HEAP Corruption detected at: void FLAC__bitreader_free(FLAC__BitReader *br) { FLAC__ASSERT(0 != br); if(0 != br->buffer) free(br->buffer); The call stack is: >

In FLAC 1.2.0, a new field 'FLAC__CPUInfo cpu_info' was added to the struct FLAC__BitReader. It became useless in 1.3.0 because of various bitreader optimizations. The first patch removes it and also removes FLAC__CPUInfo argument of FLAC__bitreader_init() function. The second patch removes a comment about struct FLAC__BitReader. It seems that it should really belong to

- INCLUDES is deprecated, and CPPFLAGS is an user-defined variable, use the proper AM_CPPFLAGS instead - Remove FLAC__INLINE definition, providing proper replacement for MSVC compilers. - Detect if we have C99 's lround and provide a replacement for windows... --- configure.ac | 32 ++++++++-------------------- examples/c/decode/file/Makefile.am

Cristian Adam wrote: > Hi all, > > I've made a test release for Ogg DirectShow Codecs. > You can find it here: > http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe > > The problem is that I get a HEAP Corruption detected at: > > void FLAC__bitreader_free(FLAC__BitReader *br) > { > FLAC__ASSERT(0 != br); > > if(0 != br->buffer)

--- src/libFLAC/bitreader.c | 4 ++-- src/libFLAC/bitwriter.c | 4 ++-- src/plugin_xmms/plugin.c | 2 +- src/share/utf8/charset.c | 1 + src/test_libFLAC++/encoders.cpp | 8 ++++---- src/test_libFLAC/decoders.c | 4 ++-- src/test_libFLAC/encoders.c | 8 ++++---- 7 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/libFLAC/bitreader.c

On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote: > Take, for example, the function FLAC__bitreader_is_consumed_byte_aligned. > It is prototyped in bitreader.h It is used in stream_decoder.c, so it > must be defined and made available to the linker ("external definition"). > However, the only definition in bitreader.c has been declared inline. > > From

> On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote: >> From 6.7.4.6 >> An inline definition does not provide an external definition for the >> function, and does not forbid an external definition in another >> translation unit. An inline definition provides an alternative to an >> external definition, which a translator may use to implement any call to

Pulled from my Arch archive, this following patch seems to have made quite a difference in getting my ARM7TDMI chip to play FLAC (compression levels 0-2) on my ipod. I don't have benchmarks with hard numbers, but playing with skips vs playing without skips is a fairly noticeable difference. memcpy and memset on uClibc are optimized in asm for the ARM7TDMI in uClibc. Other hardware/libc

Ben Allison wrote: > There's a more few issues for compiling on MSVC. I put together a patch. > > Here's a quick rundown: > * must use __inline keyword with static inline functions (bitmath.h) If you include "share/compath.h" you will get a inline #defined as __inline when _MSC_VER is defined. I'd prefer a single diffinition of that in one place and one place

Johnny Rosenberg wrote: > Maybe a stupid question, but I was born stupid and I have walked that > path ever since, so: Is there a changelog? The only changelog is the git changelog. I will be writing a real changelog to go in the actual release tarball before the official release. The git changelog is available here: https://git.xiph.org/?p=flac.git;a=summary or in any git clone of

I have datetime (SQL) column in my DB, and I noticed whenever I retrieve that column using ActiveRecord, it returns an object of class Time instead of DateTime. Does Rails convert treat datetime and time as if they''re the same? Eric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: