flac dev - May 2013 - Bug fix and compatibility patches for 1.3.0pre4

On 6.5.2013 0:43, Timothy B. Terriberry wrote:
> Janne Hyv?rinen wrote:
>> You people do realize these hacks would only be required for 10+ year
>> old obsolete compilers?
> No, they're required for easy distribution on 12 year old OSes (which,
> last I saw, make up almost 40% of Firefox's desktop userbase, and
likely
> will continue to for some time).
>
What kind of nonsense is this? You should know that the last Microsoft 
compiler to create dynamically linked code that used msvcrt.dll was 
Visual Studio 6.0 from 1998.

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.

If you take a look at the following MSDN pages for Visual Studio 2005, 
you will see that _fseeki64 and _ftelli64 are supported all the way back 
to Windows 95:
http://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.80%29.aspx and
http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx

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...

Robert Kausch wrote:
> 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
Sigh, I thought we'd finally gotten rid of most of this kind of API 
brokenness from the Xiph libraries.

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
>