Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Fri, May 04, 2012 at 06:09:06PM +0200, Miroslav Lichvar wrote: On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. Will be this patch included in the upcoming release? Or does it need more work before it can be accepted? -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote: El 03/05/12 12:19, Miroslav Lichvar escribió: It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. With current compilers it is very likely that those routines are already superflous. It seems the current compilers are not that good yet :). In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote: In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. Was that with -O2 or -O3? Not sure, I didn't set CFLAGS which seems to result in using both: -O3 -funroll-loops -Wall -W -Winline -g -O2 I think funroll-loops can be harmful, the Fedora package is compiled with -O2 and funroll-loops is used only for the stream_encoder file and it seems decoding is a tiny bit faster than with the git version. Unfortunately I don't recall the details. On Mon, May 07, 2012 at 01:23:03PM -0400, Cristian Rodríguez wrote: Did you build with -fprofile-generate ... then make check .. then rebuild with -fprofile-use ? No, I have not tried that. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 07/05/12 13:37, Miroslav Lichvar escribió: On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote: In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. Was that with -O2 or -O3? Not sure, I didn't set CFLAGS which seems to result in using both: -O3 -funroll-loops -Wall -W -Winline -g -O2 I think funroll-loops can be harmful, the Fedora package is compiled with -O2 and funroll-loops is used only for the stream_encoder file and it seems decoding is a tiny bit faster than with the git version. Unfortunately I don't recall the details. On Mon, May 07, 2012 at 01:23:03PM -0400, Cristian Rodríguez wrote: Did you build with -fprofile-generate ... then make check .. then rebuild with -fprofile-use ? No, I have not tried that. Yes, -funroll-loops might cause code growth and/or make binaries actually slower... BTW, just wondering, how are you measuring the speed in this tests ? I would be interested to know so I can reproduce it here with different compile/link options ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
From: Miroslav Lichvar mlich...@redhat.com Sent: Friday, May 4, 2012 9:09 AM On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. Excellent! ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 03/05/12 12:19, Miroslav Lichvar escribió: Hi Josh, nice to see you here again. On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: (Jumping in again, maybe at the wrong point since this doesn't seem to involve encoding, but here goes.) Miroslav's patches have always been high-quality for sure. But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. If there were ever a libFLAC release that had a bug and was not always lossless, that would be very damaging to the format. The bitreader patch touches only the rice decoding code which I believe is very well covered by the test suite and any bugs would be quickly seen. Also, it has also been included in the Fedora packages for several years, no bug reports about MD5 mismatch were received yet :). It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. I'm not sure if anyone is planning to port the asm code to x86_64, I think that it will be quite a lot of work, perhaps it would be a good time to reconsider using inline assembly instead of nasm to minimize the amount of asm code? It would be useful to know how much are the individual asm routines actually faster, it has been a long time since I played with it. Hi: Both Erick and I did already submitted patches to the tree that do just exactly what your flac-1.2.1-bitreader.patch intended.. please checkout current GIT tree. Cheers! ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 03/05/12 12:19, Miroslav Lichvar escribió: It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. With current compilers it is very likely that those routines are already superflous. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Fri, May 04, 2012 at 11:13:05AM -0400, Cristian Rodríguez wrote: Both Erick and I did already submitted patches to the tree that do just exactly what your flac-1.2.1-bitreader.patch intended.. please checkout current GIT tree. The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. BTW, how much faster is the code with the clz builtin? If the architecture doesn't have the instruction, will be the gcc code as fast as the original code? -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 04/05/12 11:53, Miroslav Lichvar escribió: On Fri, May 04, 2012 at 11:13:05AM -0400, Cristian Rodríguez wrote: Both Erick and I did already submitted patches to the tree that do just exactly what your flac-1.2.1-bitreader.patch intended.. please checkout current GIT tree. The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Ah ok, I will check it out ! BTW, how much faster is the code with the clz builtin? If the architecture doesn't have the instruction, will be the gcc code as fast as the original code? I do not have access to a host that does not have either bsr, clz, lzcnt, cntlz or ctlz. if you do, plz share your results ;) I have no idea what code will be generated in exotic archs, in x86 it translates to bsr ^ 31U and in the others supported to a single instruction. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 04/05/12 12:09, Miroslav Lichvar escribió: On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. Looking at the openSUSE trees, we carry this patch since Aug 2011 and have recieved no reports on it being broken, also it works fine in my machine ;) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Largest risks are: 1) encoding errors in a scenario not exercised by the tests 2) violations of the spec that are tolerated by the decoder. I've seen this before with, e.g. x264, where a bug is repeated in the encoder and decoder and hence not caught by any tests. On Apr 26, 2012, at 2:49 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Josh Coalson wrote: From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. What exactly is the problem? New versions of the encoder producing files that can't be decoded by older decoders or something else? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 12-04-25 5:11 PM, Josh Coalson wrote: Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Coverage of the test suite is something the test suite could be extended to measure. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. Sadly, this remains true anyway. It's best to have both automatic and human checks. Both are fallible. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Op 26-04-12 10:27, Ben Allison schreef: I've seen this before with, e.g. x264, where a bug is repeated in the encoder and decoder and hence not caught by any tests. So, would it be useful to include some of tests run by another (or several other) decoder(s)? Probably an older FLAC release of some 3rd party decoder, I guess there are quite some implementations. Yes, that's even more dependencies and once more increasing the test suite run length. However, as said earlier, a release with an encoder error is probably the worst thing that can happen to FLAC. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Josh Coalson wrote: From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. What exactly is the problem? New versions of the encoder producing files that can't be decoded by older decoders or something else? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 2/3/2012 06:33, JonY wrote: On 2/3/2012 02:50, Erik de Castro Lopo wrote: JonY wrote: Attached patch builds without any warnings for MinGW. Sorry JonY, that patch does not apply against current git master which is here: https://git.xiph.org/?p=flac.git;a=summary Specifically I pulled out much of the #ifdef _MSC_VER printf stuff in this commit: https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 For example (damn thats a horrible URL): https://git.xiph.org/?p=flac.git;a=blobdiff;f=examples/c/decode/file/main.c;h=e5138b4f9a08f0cf3e9a26c8ab68ac76d161785d;hp=32b555947d5c576693dbb6a9ee13a0a67582d96a;hb=ce8a75134cace056f6c436d54b57bad1a1d93797;hpb=8bbbf56403808ff75126cd0840a936aedbc4113b Since your patch seems pretty similar to what I have already commited, I wouldn't be surprised it what we have now doesn't just compile correctly under MinGW. OK, will redo patch later today. My git repo still pointed to the old /mirrors/flac.git link, so I didn't get any updates. OK, rebuilt with latest master, no more printf warnings. Here's another attached patch to suppress redefinition warnings with mingw-w64 lfs64 support. diff --git a/src/flac/decode.c b/src/flac/decode.c index 05d86f3..2173669 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -29,10 +29,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include errno.h #include math.h /* for floor() */ #include stdio.h /* for FILE etc. */ diff --git a/src/flac/encode.c b/src/flac/encode.c index dafa105..87ef2ef 100644 --- a/src/flac/encode.c +++ b/src/flac/encode.c @@ -29,10 +29,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include errno.h #include limits.h /* for LONG_MAX */ #include math.h /* for floor() */ diff --git a/src/flac/foreign_metadata.c b/src/flac/foreign_metadata.c index 7e273a5..d4fb7c2 100644 --- a/src/flac/foreign_metadata.c +++ b/src/flac/foreign_metadata.c @@ -23,10 +23,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include stdio.h /* for FILE etc. */ #include stdlib.h /* for calloc() etc. */ #include string.h /* for memcmp() etc. */ diff --git a/src/flac/iffscan.c b/src/flac/iffscan.c index da74a5f..2cb9075 100644 --- a/src/flac/iffscan.c +++ b/src/flac/iffscan.c @@ -26,10 +26,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include foreign_metadata.h static FLAC__uint32 unpack32be_(const FLAC__byte *b) diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index ac6473e..9ef9882 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -47,9 +47,13 @@ #include io.h /* for chmod() */ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif +#endif #else #include sys/types.h /* some flavors of BSD (like OS X) require this to get time_t */ #include utime.h /* for utime() */ diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index 72d9e43..0323d73 100644 --- a/src/libFLAC/stream_decoder.c +++ b/src/libFLAC/stream_decoder.c @@ -48,10 +48,14 @@ #include sys/types.h /* for off_t */ #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__ #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include FLAC/assert.h #include share/alloc.h #include protected/stream_decoder.h diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c index 8fb3209..0b6d8c2 100644 --- a/src/libFLAC/stream_encoder.c +++ b/src/libFLAC/stream_encoder.c @@ -48,10 +48,14 @@ #include sys/types.h /* for off_t */ #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__ #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include FLAC/assert.h #include FLAC/stream_decoder.h #include share/alloc.h diff --git a/src/test_libFLAC/decoders.c b/src/test_libFLAC/decoders.c index e45e722..70127cf 100644 --- a/src/test_libFLAC/decoders.c +++
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 2/1/2012 22:36, JonY wrote:
On 2/1/2012 18:52, Erik de Castro Lopo wrote:
JonY wrote:
Alright, here's a quick fix, although it is more ugly than I remembered.
Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
where available, and falls back to I64 on MSVC and then ll for others,
all format warnings suppressed.
JonY,
Sorry for the delay on actually getting on to this.
I tried your patch, but it wasn't quite right. The problem is that %ll
is the correct format specifier for uint64_t on 32bit Linux but not
on 64 bit Linux.
Something is very very wrong about the above statements. I thought I
used PRI?64 when inttypes.h is found (Linux should have it, old code
uses %ll? anyway for non-msvc, so shouldn't have any new issues).
inttypes.h and stdint.h is supposed to be abstractions to remove these
issues.
In C99, the correct way to print a uint64_t value is:
printf (THe value is : PRIu64 \n, value) ;
I have gone ahead and fixed this through the code and fixed this, but I
may have broken some either MSVC or MinGW on the way. I'd appreciate it
if you test whats in git now.
For those files where any compiler baulks at the PRIu64/PRIx64/PRId64,
you should add a #ifdef block that might look something like:
#ifdef HAVE_INTTYPES_H
#include inttypes.h
#else
#if defined (_MSC_VER) ! defined (PRId64)
#define PRId64 I64d
#endif
#if defined (_MSC_VER) ! defined (PRIu64)
#define PRIu64 I64u
#endif
#endif
We'll worry about compilers that don't have the PRI_64 values as we find
them.
OK, I'll do a quick test build tomorrow. More thorough testing will come
during the weekends.
Attached patch builds without any warnings for MinGW.
diff --git a/examples/c/decode/file/main.c b/examples/c/decode/file/main.c
index 32b5559..67028bb 100644
--- a/examples/c/decode/file/main.c
+++ b/examples/c/decode/file/main.c
@@ -31,6 +31,7 @@
#include stdio.h
#include stdlib.h
#include FLAC/stream_decoder.h
+#include FLAC/compat.h
static FLAC__StreamDecoderWriteStatus write_callback(const FLAC__StreamDecoder
*decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void
*client_data);
static void metadata_callback(const FLAC__StreamDecoder *decoder, const
FLAC__StreamMetadata *metadata, void *client_data);
@@ -174,11 +175,7 @@ void metadata_callback(const FLAC__StreamDecoder *decoder,
const FLAC__StreamMet
fprintf(stderr, sample rate: %u Hz\n, sample_rate);
fprintf(stderr, channels : %u\n, channels);
fprintf(stderr, bits per sample: %u\n, bps);
-#ifdef _MSC_VER
- fprintf(stderr, total samples : %I64u\n, total_samples);
-#else
- fprintf(stderr, total samples : %llu\n, total_samples);
-#endif
+ fprintf(stderr, total samples : %PRIu64\n, total_samples);
}
}
diff --git a/examples/c/encode/file/main.c b/examples/c/encode/file/main.c
index 0f7f4c0..9be55b0 100644
--- a/examples/c/encode/file/main.c
+++ b/examples/c/encode/file/main.c
@@ -33,6 +33,7 @@
#include string.h
#include FLAC/metadata.h
#include FLAC/stream_encoder.h
+#include FLAC/compat.h
static void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64
bytes_written, FLAC__uint64 samples_written, unsigned frames_written, unsigned
total_frames_estimate, void *client_data);
@@ -164,10 +165,5 @@ int main(int argc, char *argv[])
void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64
bytes_written, FLAC__uint64 samples_written, unsigned frames_written, unsigned
total_frames_estimate, void *client_data)
{
(void)encoder, (void)client_data;
-
-#ifdef _MSC_VER
- fprintf(stderr, wrote %I64u bytes, %I64u/%u samples, %u/%u frames\n,
bytes_written, samples_written, total_samples, frames_written,
total_frames_estimate);
-#else
- fprintf(stderr, wrote %llu bytes, %llu/%u samples, %u/%u frames\n,
bytes_written, samples_written, total_samples, frames_written,
total_frames_estimate);
-#endif
+ fprintf(stderr, wrote %PRIu64 bytes, %PRIu64/%u samples, %u/%u
frames\n, bytes_written, samples_written, total_samples, frames_written,
total_frames_estimate);
}
diff --git a/include/FLAC/compat.h b/include/FLAC/compat.h
new file mode 100755
index 000..831d882
--- /dev/null
+++ b/include/FLAC/compat.h
@@ -0,0 +1,57 @@
+/* libFLAC - Free Lossless Audio Codec library
+ * Copyright (C) 2001,2002,2003,2004,2005,2006,2007,2008,2009 Josh Coalson
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. JonY, Sorry for the delay on actually getting on to this. I tried your patch, but it wasn't quite right. The problem is that %ll is the correct format specifier for uint64_t on 32bit Linux but not on 64 bit Linux. In C99, the correct way to print a uint64_t value is: printf (THe value is : PRIu64 \n, value) ; I have gone ahead and fixed this through the code and fixed this, but I may have broken some either MSVC or MinGW on the way. I'd appreciate it if you test whats in git now. For those files where any compiler baulks at the PRIu64/PRIx64/PRId64, you should add a #ifdef block that might look something like: #ifdef HAVE_INTTYPES_H #include inttypes.h #else #if defined (_MSC_VER) ! defined (PRId64) #define PRId64 I64d #endif #if defined (_MSC_VER) ! defined (PRIu64) #define PRIu64 I64u #endif #endif We'll worry about compilers that don't have the PRI_64 values as we find them. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Bastiaan Timmer wrote: Well, I have been away a couple of days, so I don't know if I'm in time, but I reported a memory leak and submitted a patch a couple of months ago. It would be nice if it can make it in. I first reported the leak here: http://lists.xiph.org/pipermail/flac-dev/2011-August/003002.html And the patch is here: http://sourceforge.net/tracker/?func=detailaid=3390048group_id=13478atid=313478 I've applied that patch. Thanks. I'll be working my way through the rest on SF.net in next week or two. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
LRN wrote: Is it wise to aim at C99? While i have absolutely nothing against it, it is a known fact that MS never got around to support C99 in MSVC to any considerable degree. The idea is to only use the bits of C99 that can be worked around in MSVC with #ifdefs and #defines. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 2/1/2012 18:52, Erik de Castro Lopo wrote: JonY wrote: Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. JonY, Sorry for the delay on actually getting on to this. I tried your patch, but it wasn't quite right. The problem is that %ll is the correct format specifier for uint64_t on 32bit Linux but not on 64 bit Linux. Something is very very wrong about the above statements. I thought I used PRI?64 when inttypes.h is found (Linux should have it, old code uses %ll? anyway for non-msvc, so shouldn't have any new issues). inttypes.h and stdint.h is supposed to be abstractions to remove these issues. In C99, the correct way to print a uint64_t value is: printf (THe value is : PRIu64 \n, value) ; I have gone ahead and fixed this through the code and fixed this, but I may have broken some either MSVC or MinGW on the way. I'd appreciate it if you test whats in git now. For those files where any compiler baulks at the PRIu64/PRIx64/PRId64, you should add a #ifdef block that might look something like: #ifdef HAVE_INTTYPES_H #include inttypes.h #else #if defined (_MSC_VER) ! defined (PRId64) #define PRId64 I64d #endif #if defined (_MSC_VER) ! defined (PRIu64) #define PRIu64 I64u #endif #endif We'll worry about compilers that don't have the PRI_64 values as we find them. OK, I'll do a quick test build tomorrow. More thorough testing will come during the weekends. signature.asc Description: OpenPGP digital signature ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: Sorry for the delay on actually getting on to this. I tried your patch, but it wasn't quite right. The problem is that %ll is the correct format specifier for uint64_t on 32bit Linux but not on 64 bit Linux. Something is very very wrong about the above statements. I thought I used PRI?64 when inttypes.h is found (Linux should have it, old code uses %ll? anyway for non-msvc, so shouldn't have any new issues). I think that may have been because configure was not detecting inttypes.h when I first tested that patch. inttypes.h and stdint.h is supposed to be abstractions to remove these issues. For the inttypes.h and stdint.h problem the way I usually prefer to tackle it is: a) Assume they are there. b) When they aren't, add the required #ifdef/#define nonsense to define them for the compiler when they are missing. OK, I'll do a quick test build tomorrow. More thorough testing will come during the weekends. Cool, thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 12/06/2011 08:44 AM, Erik de Castro Lopo wrote: Sven-Hendrik Haase wrote: Sooo any news? Unfortunately, my day job, my family and a bunch of other commitments have been getting in my way. I *know* I will have some free time between xmas and new year. I have no guarantees of any decent block of time showing up before that. Erik Poke ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
