Erik de Castro Lopo wrote:
Also fixed. Thanks.
There's also src/share/utf8/Makefile.am file that has the same issues.
(I don't know why utf8 source files are included in two makefiles, one
is src/share/Makefile.am and another is src/share/utf8/Makefile.am)
utf8_Makefile.patch
Description: B
I'm study FLAC decode problem, but can't figure out how to get FLAC frame
length. Please help.https://xiph.org/flac/format.html I docoded
METADATA_BLOCK_STREAMINFO, and get below data:
mMinBlock: 4096
mMaxBlock: 4096
mMinFrame: 1201
mMaxFrame: 12804
mSampleRate: 44100
mBitPerSample: 16
mTotalSampl
The patch adds check of the result of make_utf8_string(),
similar to the existing check of make_unicode_string().
utf8_addcheck.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 avo
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 defi
seek_barrage() has variable n of type long int (which is 32bit usually).
Then we see something like
n = (long int)total_samples;
So, why n has type long int, and not FLAC__int64 or some other 64-bit type?
___
flac-dev mailing list
flac-dev@xiph.org
Brian Willoughby писал(а) в своём письме 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 o
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 big
lvqcl wrote:
> The patch adds check of the result of make_utf8_string(),
> similar to the existing check of make_unicode_string().
Applied. Thanks.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
__
lvqcl wrote:
> a) replace all flac_fopen() calls inside test_streams/main.c with
> fopen()
fopen() is part of the original ISO C spec from the 1980s. I don't
think we support anything wouldn't have a working fopen().
Erik
--
--
Brian Willoughby wrote:
> p.s. You mentioned that flac_fopen() makes test_streams dependent upon
> libFLAC, but I do not understand why that is a problem. Doesn't the test
> software have to link to the flac libraries in order to test them?
Yes, but flac_fopen() is not part of the public API and
lvqcl wrote:
> seek_barrage() has variable n of type long int (which is 32bit usually).
Thats true on Windows, but on both 32 and 64 bit linux sizeof (long int)
is 8.
> Then we see something like
>
> n = (long int)total_samples;
>
> So, why n has type long int, and not FLAC__int64 or some
Agreed.
Although there wasn't a universal standard when FLAC was started, it sure seems
like int64_t and related types are available on all systems these days. Either
FLAC__intXX or intXX_t are better than the old types, like byte, word, dword,
quadword, or whatever.
Brian
On Jan 31, 2016, a
13 matches
Mail list logo
