[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] mingw build failure

From: Antonio Diaz Diaz
Subject: Re: [Lzip-bug] mingw build failure
Date: Mon, 14 Jan 2013 14:26:52 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

JonY wrote:
I think Roy meant strtoull is missing from the headers, if so,
_strtoui64 should be fine since it is already guarded by __MSVCRT__.

I think Roy meant _strtoi64 is missing from the headers. He was reporting about rc2, which had this code:

  #if defined(__MSVCRT__)
  #define strtoull _strtoi64

And he wrote this:

for strtoull in mingw, use _strtoui64. (
http://msdn.microsoft.com/en-US/library/85zk715d%28v=vs.80%29.aspx )
for document about _strtoi64, it isavailable here:
but g++ complains there is no header about it, I think keep using
strtoll/strtoull in C++ version will be better.
(the function exists in MSVCRT.dll but mingw header does not have prototypes)

I still think the most correct way is to get mingw to fix their headers
since the function actually exists, just unexposed. I dislike these
define hacks, especially on a still active target.

I agree that fixing mingw headers is the most correct way, but my main priority in this case is to get lzip working on windows with the minimum effort from my part. Roy's message seems to imply that the C version (clzip) may have problems with strtoll/strtoull. So, defining strtoull to strtoul solves any present and future problems, and I doubt any user is going to even notice the change.

As you may have noticed, almost all problem reports on lzip had not been real bugs, but compilation problems on some sort of windows environment. All the 9 "define hacks" contained in the code of lzip are meant to make it compile on windows.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]