Re: [Lzip-bug] mingw build failure

[Antonio Diaz Diaz]

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
  #endif

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:
> http://msdn.microsoft.com/en-US/library/h80404d3%28v=vs.80%29.aspx
> 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.


Regards,
Antonio.