[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
signature.asc
Description: OpenPGP digital signature
