bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT

[Kees Dekker]

Hi Bruno,

Thanks for reply.

>> 1.      frexp.c is not needed, as Visual Studio already provides frexp() 
>> function via system libraries.

...

>Do you have data that shows that MSVC14's frexp() behaves better than the one 
>in MSVC 9?

Do you have advice how I can check this quickly? Visual Studio 2015 is VC14, so 
may be 5 versions ahead, something may be fixed? If you have a test code, I 
will check for you.

>> 4.      lseek.c: need to include winsock2.h before including windows.h

>I'm not observing this problem with building this gzip snapshot.

I have used configure to let it generate the required headers, but finally, all 
was imported in a visual studio project, so my final compile is using visual 
studio itself (and therefore may be using slightly different defaults, as I use 
some base property sheets to globally define some settings, e.g. whole program 
optimization for optimized builds and some other defines and settings).

>> 5.      utimens.c: need to include sys/times.c on Windows to get struct 
>> utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +

>Likewise: I'm not observing this problem.

Probably same cause, due to my native visual studio compilation.

>> 7.      config.h (stored in clearcase as config_win32.h): added typedefs for 
>> uid_t and gid_t.

>config.h is autogenerated with my README.windows instructions.

There is no README.windows file in the tar.gz file of the gzip sources, so it 
would be very handy to add it there. This email chain told me that there is 
something like README.windows for gnulib....

>> 9.      util.c/xalloc-die.c: both contain a xalloc_die() function. I guess 
>> this is intentionally?

>The one in util.c is meant to override the one from gnulib. This is normally 
>achieved by having the gnulib code linked as a library.

But it IMO still strange to have two different prototypes for a similar 
function (that got implemented in two places). If these are harmonized, then 
there is no problem. The order of including header files may now conflict with 
the implementation that comes first...

Kees