On Apr 12, 2011, at 12:36 AM, Jakub Zawadzki wrote:
> Attaching some small fixes.
Checked in.
> btw. what do you think about merging GZWFILE_T and WFILE_T?
> (i.e. using one API for writting files, wfile_open(), wfile_write(), ...)
Currently, a WFILE_T is a void * that, depending on the settin
On Mon, Apr 11, 2011 at 02:36:17PM -0700, Guy Harris wrote:
>
> On Apr 11, 2011, at 9:12 AM, Guy Harris wrote:
>
> > I'll look at getting rid of the use of the zlib gz* routines for
> > output (just as we've done for input)
>
> Done, as of revision 36563.
Attaching some small fixes.
btw. what do
Hi Guy,
2011/4/11 Guy Harris
>
> On Apr 11, 2011, at 9:12 AM, Guy Harris wrote:
>
> > I'll look at getting rid of the use of the zlib gz* routines for output
> (just as we've done for input), so that we're not hosed by whatever
> bogosities particular versions of zlib have in their large file su
On Apr 11, 2011, at 9:12 AM, Guy Harris wrote:
> I'll look at getting rid of the use of the zlib gz* routines for output (just
> as we've done for input), so that we're not hosed by whatever bogosities
> particular versions of zlib have in their large file support.
Done, as of revision 36563.
On Apr 11, 2011, at 5:28 AM, Pascal Quantin wrote:
> for the record, current trunk (revision 36552 as I'm speaking) does not
> compile on my Debian Lenny machine. I get the following error:
> cc1: warnings being treated as errors
> file_access.c: In function ‘wtap_dump_file_open’:
> file_access.
Hi,
for the record, current trunk (revision 36552 as I'm speaking) does not
compile on my Debian Lenny machine. I get the following error:
cc1: warnings being treated as errors
file_access.c: In function ‘wtap_dump_file_open’:
file_access.c:1016: error: implicit declaration of function ‘gzopen64’
