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.)
>
>
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
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 externa
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
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 f
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 p
On 5/7/2013 11:04, Ben Allison wrote:
> 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
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
dy
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
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 msvc
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 sti
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
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), so
> I don't think it's a good idea to use it this way even if tests
> suggested it wor
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*."
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 o
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 mea
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)
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 compiler
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.
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
>
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
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 add
22 matches
Mail list logo
