gzstream для windows через mingw: внедряет CR + LF - PullRequest
1 голос
/ 16 сентября 2011

Я скачал исходный код с сайта и собрал его, но при запуске теста все сжатые файлы имеют окончания строк CR + LF, а не только LF, что делает разархивированные файлы отличными от оригиналов,

Я смотрю на источник, но кажется, что они уже открывают файл в двоичном режиме:

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;
}

Я бы очень хотел использовать этот фрагмент кода, потому что он выглядиточень чистый и легко собирается на mingw gcc.Единственная проблема - это хитрый бизнес, который я мог бы опустить, если бы мог найти решение для него.

Ответы [ 2 ]

2 голосов
/ 16 сентября 2011

Я успешно реализовал мой обходной путь. Несмотря на то, что gzstream выглядит хорошо, я укусила пулю и просто написала код, который напрямую использует zlib. Оказывается, это было неплохо вообще , потому что в zlib есть скрытые помощники, а также множество полезных комментариев в самом zlib.h.

ZEXTERN int ZEXPORT compress OF((Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen)); достаточно просто.

И, конечно же, больше никаких проблем с ложными 0x0D символами возврата каретки!

1 голос
/ 26 сентября 2011

Где находится std :: ios :: binary ??

На платформах UNIX это часто не нужно, поэтому некоторые люди пропускают его, когда не должны.

...