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:
>>
>> https://sourceforge.net/p/flac/bugs/413/
>>
>> 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?
>
>1)
>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?
>
>
>2)
>VC projects contain relative paths such as "..\..\include". Is it
better to
>leave them as is or to change to something like
"$(SolutionDir)include"?
>
>3)
>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):
>
>
http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21
>
http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14
>
>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.
--ian