Ah, ok. I was thinking along the lines of FLAC__int32, where the intention is to
be portable without depending upon any specific system. I assumed that
flac_fopen() came from that design pattern.
If it's really only a few years old, and not original, then changing it back
should be fine.
A bigger question might be: how are file opens handled in most flac code?
It's probably best for test_streams to be consistent.
Brian
p.s. You mentioned that flac_fopen() makes test_streams dependent upon libFLAC,
but I do not understand why that is a problem. Doesn't the test software
have to link to the flac libraries in order to test them?
On Jan 31, 2016, at 1:01 PM, lvqcl <lvqcl.mail at gmail.com>
wrote:> Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ??????
Sun, 31 Jan 2016 22:26:40 +0300:
>> My assumption is that the code was written to call flac_fopen() so that
it is portable to every operating system, even those without fopen(). If you
replace flac_fopen() with fopen(), then the tests won't compile on systems
that don't have fopen().
>
> I REALLY doubt it. Even if such systems exist, there's little reason
> to support test_streams on them.
>
> fopen() was changed to flac_fopen() here:
>
https://git.xiph.org/?p=flac.git;a=commitdiff;h=5705b4d7b2c3c5311138e9f4b66658c51f3cc22b#patch64
> as a part of "Huge Windows utf8 I/O patch from Janne Hyv?rinen".
>
>> You could simply have the following:
>>
>> #if defined _MSC_VER || defined __MINGW32__
>> #define flac_fopen fopen
>> #endif
>>
>> In a header, or simply at the top of test_streams/main.c where
there's already some conditional compilation.
>
> Currently flac_fopen is already defined as fopen on non-MS systems.
> So it's simpler to change flac_fopen back to fopen in this file.