[Top][All Lists]

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

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

From: Eric Blake
Subject: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Date: Mon, 6 Feb 2017 12:05:49 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

[adding gnulib]

On 02/06/2017 09:28 AM, Kees Dekker wrote:
> Hi,
> I tried to compile gzip with visual studio 2015. Unfortunately, a few files 
> could not be ported. Microsoft has redesigned the core CRT which affects the 
> visibility of (hidden/internals) of e.g. the FILE type. None of the internals 
> of the FILE type is not visible anymore (contrary to Visual Studio 2013 and 
> before). This affects e.g. freadingc, fpurge.c, fseeko.c, fseterr.c.
> If something else than gcc/glibc is used, then each change - up to everything 
> that the OS/libc/compiler vendor found as useful - may break gzip. Is it not 
> bad programming practice to do so?

It may be undesirable programming practice, but it beats the alternative
of not compiling at all, and is forced upon us because we WANT access to
these useful low-level details of FILE streams for optimal behavior,
even though those details are not standardized and therefore not
universally available without resorting to peeking inside the struct.

> My questions are:
> 1.       why does gzip use and rely on these internals?

gzip is just using gnulib code; but gnulib does it because there are
some algorithms that really do require more information about the
current state of the FILE's buffers than what you can get through just
the standardized putc/getc interfaces.

If you can help port gnulib to the newer visual studio 2015, I'm sure
patches are welcome.

> 2.       Is it intended that gzip should NOT compile on anything else where 
> gcc/glibc is not used?

No; gnulib tries to make the various FILE manipulation functions
available on as many platform/compiler combinations as possible.  It's
sometimes an arms race when platforms change, but we welcome patches to
catch back up to the current state of things.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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