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

On 5/5/2013 09:03, Timothy B. Terriberry wrote:
> Robert Kausch wrote:
>> 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.
> 
> _lseeki64 operates on the underlying file handle, and does not interact 
> well with the buffering in stdio streams. I _think_ you can use this 
> successfully if you call fflush() beforehand (as this sets FILE::_cnt to 
> 0 and FILE::_ptr to FILE::_base). By which I mean I read the MSVCRT 
> source from MSVC6.0 and it appears this is how things work.
> 
How about just forgetting about base XP and require at least SP2 or some
such? Alternatively, use win32api underneath instead, eg
CreateFileW/SetFilePointer.
> That source also includes an fseeki64()/ftelli64(), but they are not 
> defined in stdio.h. I wonder if just declaring it yourself is good 
> enough? If not, they get called by fsetpos()/fgetpos() (which _do_ 
> interact correctly with the buffering in stdio streams), except when 
> _MAC is defined (which I presume is not common). I don't actually have 
> XP to test against.
Bad, do no declare manually, I had to cleanup some bad code recently
that make assumptions about your header declarations. You can try using
GetModuleHandle/GetProcAddress instead, but msvcr* versions are a whole
different can of worms.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
Url :
http://lists.xiph.org/pipermail/flac-dev/attachments/20130505/e7754bf3/attachment.pgp

JonY wrote:
> How about just forgetting about base XP and require at least SP2 or some
> such? Alternatively, use win32api underneath instead, eg
> CreateFileW/SetFilePointer.
This requires replacing _all_ of the FILE I/O, not just these two 
functions, which is a lot more work to no clear advantage. The _lseeki64 
implementation uses SetFilePointer internally, but doing that directly 
without changing everything else has the same problems using _lseeki64 does.
> Bad, do no declare manually, I had to cleanup some bad code recently
> that make assumptions about your header declarations. You can try using
Windows headers are usually well-defined enough that you can get away 
with it (upgrade cycles are slow and changes would break lots of 
systems, so things don't change). But according to some random page on 
the internet, this function is not exposed in the msvcrt.dll distributed 
with XP. So this wouldn't work anyway.

Instead I've attached a patch that uses fgetpos/fsetpos. This is totally 
untested (I haven't even checked it compiles), but the idea should work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-fgetpos-fsetpos-for-64-bit-win32-fseek-ftell.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/flac-dev/attachments/20130505/5bbec174/attachment.bin

On 5.5.2013 18:02, Timothy B. Terriberry wrote:
>
> Instead I've attached a patch that uses fgetpos/fsetpos. This is 
> totally untested (I haven't even checked it compiles), but the idea 
> should work.
>
You people do realize these hacks would only be required for 10+ year 
old obsolete compilers?

JonY wrote:
> How about just forgetting about base XP and require at least SP2 or some
> such? Alternatively, use win32api underneath instead, eg
> CreateFileW/SetFilePointer.
Even SP2 and SP3 do not have fseeki64/ftelli64. Using Windows API 
functions would probably be the cleanest solution, but on the other hand 
require wrappers for all file IO functions. I guess that would be too 
big of a change to make it into 1.3.0 at this point.

Timothy B. Terriberry wrote:
> Instead I've attached a patch that uses fgetpos/fsetpos. This is 
> totally untested (I haven't even checked it compiles), but the idea 
> should work.
MSDN says "The pos value is stored in an internal format and is intended 
for use only by *fgetpos* and *fsetpos*." 
(http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx), so 
I don't think it's a good idea to use it this way even if tests 
suggested it works.

I'll write a test program tomorrow to try the fflush+_lseeki64 approach.

Another solution - although a bit ugly - might be to disable buffering 
on Windows using setvbuf.