On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.m...@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 _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
