Re: [flac-dev] (no subject)
On 13-05-02 7:37 PM, Marcus Johnson wrote: Here's the Flac.xcodeproj, compressed with 7-zip as it's just a folder and can't be transmitted without being compressed, check to see if it works on your computers, and hopefully everything works. .7z isn't a normal MacOS tool. Could you please send a tar.gz or .zip instead? -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac-dev Digest, Vol 102, Issue 7
Ralph, for Mac OS you should download either the Unarchiver which is free, or Entrophy which is what I use, but it costs like $15 I believe, both support decompressing .7z and Entrophy supports compressing TO .7z On Mon, May 6, 2013 at 3:00 PM, flac-dev-requ...@xiph.org wrote: Send flac-dev mailing list submissions to flac-dev@xiph.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.xiph.org/mailman/listinfo/flac-dev or, via email, send a message with subject or body 'help' to flac-dev-requ...@xiph.org You can reach the person managing the list at flac-dev-ow...@xiph.org When replying, please edit your Subject line so it is more specific than Re: Contents of flac-dev digest... Today's Topics: 1. Re: Bug fix and compatibility patches for 1.3.0pre4 (Timothy B. Terriberry) 2. Re: Bug fix and compatibility patches for 1.3.0pre4 (Robert Kausch) 3. Re: Bug fix and compatibility patches for 1.3.0pre4 (Robert Kausch) 4. Re: Bug fix and compatibility patches for 1.3.0pre4 (Robert Kausch) 5. Re: Bug fix and compatibility patches for 1.3.0pre4 (Timothy B. Terriberry) 6. Re: Bug fix and compatibility patches for 1.3.0pre4 (Janne Hyv?rinen) 7. Re: (no subject) (Ralph Giles) -- Forwarded message -- From: Timothy B. Terriberry tterr...@xiph.org To: flac-dev@xiph.org Cc: Date: Sun, 05 May 2013 14:43:46 -0700 Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4 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). -- Forwarded message -- From: Robert Kausch robert.kau...@freac.org To: flac-dev@xiph.org Cc: Date: Mon, 06 May 2013 01:20:52 +0200 Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4 Timothy B. Terriberry wrote: _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. Ok, I didn't take that into account. Thanks for pointing it out! Using fflush to clear the buffers before calling _lseeki64 sounds reasonable, so I think I'll try that. I noticed another problem with _lseeki64 though. It returns the new file pointer position on success instead of 0, so the macro will have to take that into account. 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? Those functions are not exported by XPs msvcrt.dll, so declaring them won't help. -- Forwarded message -- From: Robert Kausch robert.kau...@freac.org To: flac-dev@xiph.org Cc: Date: Mon, 06 May 2013 01:21:56 +0200 Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4 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. -- Forwarded message -- From: Robert Kausch robert.kau...@freac.org To: flac-dev@xiph.org Cc: Date: Mon, 06 May 2013 01:26:08 +0200 Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4 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.aspxhttp://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. -- Forwarded message -- From: Timothy B. Terriberry tterr...@xiph.org To: flac-dev@xiph.org Cc: Date: Sun, 05 May 2013 16:34:04 -0700 Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4 Robert Kausch wrote: MSDN says The pos value is stored in an internal format and is intended for use only by *fgetpos* and
Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4
Timothy B. Terriberry wrote: The pos value is stored in an internal format and is intended for use only by *fgetpos* and *fsetpos*. FWIW, I verified that this is the approach used by mingw32 to implement fseeko/ftello. Yes, they do - I also had a look at the libmingwex source. But still, with that sentence Microsoft basically reserves the right to change the behaviour of fgetpos/fsetpos at any time without notice... I wrote a small test program in the meantime and verified that fgetpos/fsetpos indeed work, even back to Windows 98. _lseeki64 on the other hand totally messes up with buffered streams and cannot be used here. Calling fflush beforehand doesn't help and even fflush alone breaks the stream (i.e. with 4kB buffers, fopen()-fread()-fflush()-fread() will start at byte #4096 with the second read, so don't use fflush for reading). However, as Janne already pointed out, libFLAC is statically linked by default, so there's no real problem with _fseeki64/_ftelli64 indeed. I'll still have to decide whether to link statically or use your fgetpos/fsetpos patch for my build, but no need to change anything in the official FLAC code. In any case, please disregard my _lseeki64 patch. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4
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@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4
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. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4
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@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
