[flac-dev] Lets work towards a new version
flac at nartowicz.co.uk
Thu Jun 19 15:39:27 PDT 2014
On Thu, 19 Jun 2014 05:00:39 +0400
lvqcl <lvqcl.mail at gmail.com> wrote:
>Erik de Castro Lopo wrote:
>> It sees that the most serious bug in the flac bug tracker:
>> has been fixed in git. This fix alone is worth a new release so its
>> time to work towards one.
>> Things I need to do for this new release:
>> * Deal with all current patches on the mailing list.
>> * Review all bugs reported against 1.3.0 on the sf.net.
>> * Testing and coordination of testing across platforms and build systems.
>> Anything else I've forgotten or people would like to see?
>Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with
>VC2005 Express and doesn't allow to build 64-bit files/libraries.
>IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual
>Studio 2012/2013 Express are free and allow to build 64-bit files.
>VS 2005/2008 use .vcproj files, and VS 2010/2012/2013 use .vcxproj
>and .vcxproj.filters files, so it's possible to have two sets of
>MSVS solution files: one for 2005/2008 and another for 2010/2012/2013.
>But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln
>(or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?)
>What do you think?
>VC projects contain relative paths such as "..\..\include". Is it better to
>leave them as is or to change to something like "$(SolutionDir)include"?
>Currently there are two ia32 asm files (bitreader_asm.nasm and
>stream_encoder_asm.nasm) that are unused and not necessary to compile libFLAC:
>they offer no speed benefit and the corresponding functions were commented out
>(*after* the release of 1.3.0):
>Is it better to remove these files from Makefile and .vcproj files, or to
>leave them? I don't think that they will become useful again, but who knows...
Is it of any relevance, or perhaps already known, that libFLAC causes memory
corruption when a METADATA_BLOCK_PICTURE block is larger than the allowed 16MB?
This was just reported as crashing an application. I know that is an invalid
block size, but just rejecting it would seem better. I haven't got metaflac to
crash yet, although I did hang up my terminal on one attempt.
More information about the flac-dev