[flac-dev] flac-dev Digest, Vol 102, Issue 7

Marcus Johnson bumblebritches57 at gmail.com
Mon May 6 14:37:57 PDT 2013 

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-request at xiph.org> wrote:

> Send flac-dev mailing list submissions to
>         flac-dev at 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-request at xiph.org
>
> You can reach the person managing the list at
>         flac-dev-owner at 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" <tterribe at xiph.org>
> To: flac-dev at 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.kausch at freac.org>
> To: flac-dev at 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.kausch at freac.org>
> To: flac-dev at 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.kausch at freac.org>
> To: flac-dev at 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.aspx<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.
>
>
>
> ---------- Forwarded message ----------
> From: "Timothy B. Terriberry" <tterribe at xiph.org>
> To: flac-dev at 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 *fsetpos*."
>> (http://msdn.microsoft.com/en-**us/library/70hdhh4t%28v=vs.80%**29.aspx<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.
>>
>
> FWIW, I verified that this is the approach used by mingw32 to implement
> fseeko/ftello.
>
>
>
> ---------- Forwarded message ----------
> From: "Janne Hyvärinen" <cse at sci.fi>
> To: flac-dev at xiph.org
> Cc:
> Date: Mon, 06 May 2013 07:42:34 +0300
> Subject: Re: [flac-dev] 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<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<http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ralph Giles <giles at thaumas.net>
> To: flac-dev at xiph.org
> Cc:
> Date: Mon, 06 May 2013 11:20:15 -0700
> Subject: 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 at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20130506/1316eb4b/attachment.htm

More information about the flac-dev mailing list