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

On 25.5.2013 10:54, Erik de Castro Lopo wrote:
> Robert Kausch wrote:
>
>> Hi all,
>>
>> I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure
if
>> this is the right place to submit patches, but someone suggested this
on
>> the apparently dead SourceForge patch tracker.
>>
>> The first two are quite straight forward:
>>
>> - The ICL patch fixes a typo in bitmath.h and adds
>> FLAC__bitwriter_write_zeroes to the external declarations in
bitwriter.c.
>> - The Ogg patch replaces the check for FLAC_API_SUPPORTS_OGG_FLAC in
>> stream_decoder.c with FLAC__HAS_OGG to fix compilation with Ogg
support.
>>
>> The _lseeki64 patch probably is a little more controversial. The
problem
>> is that fseeki64 and ftelli64 are not available in Windows XP - at
least
>> not without installing extra MSVC runtime libraries. I changed compat.h
>> and replaced them with calls to _lseeki64, which was available at least
>> back to Windows 98 and thus doesn't impose such compatibility
issues.
>> However, the patch only represents my quick and dirty solution and
>> you'll probably like to find a cleaner one. Maybe all calls to
fseeko
>> and ftello should be put in OS specific wrapper functions.
>>
>> Would love to see those patches in the 1.3.0 release.
> Sorry, I've read through this thread and can't figure out what was
> actually decided and which patch I should be looking at.
>
> Clues?
>
> Erik
None. The functions in use do not prevent the program from working on 
any operating system. Their usage only requires compiler to have the 
functions, and all Microsoft Visual C compilers since version 2005 have 
them. If there is will to support older compilers it should be in some 
MSVC version dependant macro, so that new compilers don't need hacks.

Janne Hyv?rinen wrote:
> None. The functions in use do not prevent the program from working on 
> any operating system. Their usage only requires compiler to have the 
> functions, and all Microsoft Visual C compilers since version 2005 have 
> them. If there is will to support older compilers it should be in some 
> MSVC version dependant macro, so that new compilers don't need hacks.
Awesome, thanks.

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Janne Hyv?rinen wrote:
> On 25.5.2013 10:54, Erik de Castro Lopo wrote:
>> Robert Kausch wrote:
>>> I tried 1.3.0pre4 with ICL on Windows and found some issues.
>>> The first two are quite straight forward:
>>>
>>> - The ICL patch fixes a typo in bitmath.h and adds
>>> FLAC__bitwriter_write_zeroes to the external declarations in
bitwriter.c.
>>> - The Ogg patch replaces the check for FLAC_API_SUPPORTS_OGG_FLAC
in
>>> stream_decoder.c with FLAC__HAS_OGG to fix compilation with Ogg
support.
>>>
>>> The _lseeki64 patch probably is a little more controversial.
>> Sorry, I've read through this thread and can't figure out what
was
>> actually decided and which patch I should be looking at.
> None.
I think the first two patches should actually go in.

- The second patch absolutely, because it fixes an all-platform  
regression. (Actually, slightly modified perhaps; or even better, we  
revert this part to how it was in 1.2.1. Attaching a patch to do that.)

- The first patch addresses two different issues. I've split it into  
two patches (also attached). One of them fixes a mistyped variable  
name that will obviously cause the Intel compiler to fail. Regarding  
the other, well, it is certainly consistent with the other external  
declarations, and if it helps the Intel compiler, why not?

Ulrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Correctly-initialize-FLAC_API_SUPPORTS_OGG_FLAC.patch
Type: text/x-diff
Size: 0 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/flac-dev/attachments/20130525/93a1eb86/attachment.patch

On 25.5.2013 15:42, Ulrich Klauer wrote:
> Janne Hyv?rinen wrote:
>
>> On 25.5.2013 10:54, Erik de Castro Lopo wrote:
>>> Robert Kausch wrote:
>
>>>> I tried 1.3.0pre4 with ICL on Windows and found some issues.
>
>>>> The first two are quite straight forward:
>>>>
>>>> - The ICL patch fixes a typo in bitmath.h and adds
>>>> FLAC__bitwriter_write_zeroes to the external declarations in 
>>>> bitwriter.c.
>>>> - The Ogg patch replaces the check for
FLAC_API_SUPPORTS_OGG_FLAC in
>>>> stream_decoder.c with FLAC__HAS_OGG to fix compilation with Ogg
>>>> support.
>>>>
>>>> The _lseeki64 patch probably is a little more controversial.
>
>>> Sorry, I've read through this thread and can't figure out
what was
>>> actually decided and which patch I should be looking at.
>
>> None.
>
> I think the first two patches should actually go in.
>
> - The second patch absolutely, because it fixes an all-platform 
> regression. (Actually, slightly modified perhaps; or even better, we 
> revert this part to how it was in 1.2.1. Attaching a patch to do that.)
>
> - The first patch addresses two different issues. I've split it into 
> two patches (also attached). One of them fixes a mistyped variable 
> name that will obviously cause the Intel compiler to fail. Regarding 
> the other, well, it is certainly consistent with the other external 
> declarations, and if it helps the Intel compiler, why not?
>
> Ulrich
>
>
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
Ah indeed, I have nothing against those. I should have read all the 
quoted text.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20130525/6f877189/attachment.htm

Ulrich Klauer wrote:
> I think the first two patches should actually go in.
> 
> - The second patch absolutely, because it fixes an all-platform  
> regression. (Actually, slightly modified perhaps; or even better, we  
> revert this part to how it was in 1.2.1. Attaching a patch to do that.)
> 
> - The first patch addresses two different issues. I've split it into  
> two patches (also attached). One of them fixes a mistyped variable  
> name that will obviously cause the Intel compiler to fail. Regarding  
> the other, well, it is certainly consistent with the other external  
> declarations, and if it helps the Intel compiler, why not?
All three applied. Thanks.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/