[flac-dev] Bug fix and compatibility patches for 1.3.0pre4

Ben Allison benski at winamp.com
Mon May 6 20:04:53 PDT 2013


A few comments.

1) MSVCRT.DLL hasn't been used in ages.  Each version of visual studio has
its own C Runtime Library version, with a naming convention of
msvcr##.dll.  It's safe to use _fseeki64 and _ftelli64.  Leave it up to
the developer-user of FLAC to determine whether to statically link or
dynamically link.

2) Yes, the "copy" flag in the Metadata API is broken.  The APIs that take
FILE * objects as parameter are similarly broken (e.g.
FLAC__stream_decoder_init_FILE).  There's absolutely no guarantee that a
developer is using the same C library that was used to compile libFLAC.

3) For Windows C runtime libraries that are missing 64-bit seek/tell, we
can fall back to ftell and fseek and encourage those developers to use
FLAC__stream_decoder_init_stream instead.  This is also the correct way
for developers to use platform-specific I/O (CreateFile, etc).

-Ben Allison



> Janne Hyvärinen wrote:
>> Oldest Visual Studio supported by FLAC 1.3 is Visual Studio 2005. FLAC
>> is also configured to be compiled with static linking, so no external
>> dependencies hinder its function.
> Ok. Thanks for pointing this out!
>
> I use a custom build setup and link dynamically against msvcrt.dll.
> That's why I came across that problem and didn't realize that it would
> not affect most other people.
>
> Sorry for causing such a stir over this!
>
> There's one problem with static linkage and some of the FLAC API
> functions, though, that actually was the reason I linked FLAC against
> msvcrt.dll in the first place. The metadata object functions can be used
> in a memory ownership transferring manner. Doing so will cause problems
> when the calling EXE and the FLAC DLL use different CRTs as the DLL's
> CRT will not know about memory allocated by the EXE's CRT. However, the
> same happens when you mix msvcrt.dll and msvcr??.dll, so it's not
> limited to static linkage only. It's getting a bit off topic here,
> though...
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>



More information about the flac-dev mailing list