gzstream on windows via mingw: injects CR + LF

Question

I downloaded the source from the site and built it but when I run the test, all of the zipped files have CR+LF line endings rather than just LF which makes the unzipped files different from the originals.

I'm looking at the source but it seems like they are already opening the file in binary mode:

gzstreambuf* gzstreambuf::open( const char* name, int open_mode) {
    if ( is_open())
        return (gzstreambuf*)0;
    mode = open_mode;
    // no append nor read/write mode
    if ((mode & std::ios::ate) || (mode & std::ios::app)
        || ((mode & std::ios::in) && (mode & std::ios::out)))
        return (gzstreambuf*)0;
    char  fmode[10];
    char* fmodeptr = fmode;
    if ( mode & std::ios::in)
        *fmodeptr++ = 'r';
    else if ( mode & std::ios::out)
        *fmodeptr++ = 'w';
    *fmodeptr++ = 'b';
    *fmodeptr = '\0';
    file = gzopen( name, fmode);
    if (file == 0)
        return (gzstreambuf*)0;
    opened = 1;
    return this;
}

I'd really like to use this bit of code because it looks very clean and it compiled effortlessly on mingw gcc. The only problem is this tricky business which I could let slide if I can figure out a solution for it.

Answer 1

I've successfully implemented my workaround. Though gzstream looks nice I bit the bullet and just wrote some code that directly uses zlib. Turns out it wasn't bad at all because zlib has helpers hidden away in there, and also plenty of helpful comments in zlib.h itself.

ZEXTERN int ZEXPORT compress OF((Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen)); is simple enough.

And of course, no more problems with spurious 0x0D carriage-return chars!

Answer 2

Where is std::ios::binary??

On UNIX platforms it is often unnecessary so some people omit it when they should not.