Re: [Ming-dev] bug in Ming, zlib or valgrind ?

[strk <st...@ke...>]

On Fri, May 05, 2006 at 04:13:48PM +1000, Justin Clift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> strk wrote:
> <snip>
> > mmh.. I tought it was unlikely, then I saw your code :)
> 
> ;->
> 
> > I dunno if it has to do with these reported error, anyway
> > there are many problems with it:
> > 
> > 1) You're using HAVE_LIBZ macro, when it is *never*
> >    defined (it's not set in ming_config.h.in)
> 
> Hmmmm.  It should be set (or not set) by running ./configure.

configure.in has calls to set it, but then, it is required
that ming_config.h.in contains a "template" of the define
in order to have any effect.

A simple line in this form would do:

#undef HAVE_LIBZ


Still, this doesn't fix the overlap of HAVE_LIBZ and
USE_ZLIB. The concept  of USE_ZLIB is the one that should
be used to switch code, as it is independent of actually
having a libz. For some cases, you get functionalities
w/out a specific library, take iconv as an example,
somehow it is provided by libc, somehow by libiconv.
In that case ! HAVE_LIBICONV wouldn't necessarily mean
! USE_LIBICONV.
In our case, if libz is the only way to get ZLIB
functionalities we could have ./configure set USE_ZLIB
to 0 in case HAVE_LIBZ is untrue.
In any case, the .c files should only see a single
symbol for that: "USE_ZLIB".

Actually, an additional symbol would be availability
of an header file, as sometime headers are named differently
or not exist at all. For example getopt functionalities
require inclusion of <getopt.h> on some systems and none
on others, or as another example, readline header is sometimes
readline.h some other times readline/readline.h

In this cases, normal practice is to set HAVE_HEADER_H.
Example:

#ifdef HAVE_READLINE_H
# include <readline.h>
#endif
#ifdef HAVE_READLINE_READLINE_H
# include <readline/readline.h>
#endif

As it comes for library, .c code doesn't need to
know about availability of them, only Makefiles.
./configure sets ZLIB for exactly this purpose.
Can be the empty string or -lz or -lzdll, it
is appended to LDFLAGS in Makefiles.


> > 3) movie.c does not include ming_config.h, so does
> >    not have access to USE_ZLIB.
> 
> Maybe it should be adjusted?

Sure, but please consider the above considerations
and use USE_ZLIB instead.

> > I haven't checked further, but please test yourself
> > with and w/out zlib support compiled in.
> 
> Do we have test cases to use yet?

I can't successfully compile *any* code, including:

a=0;

I mean, it compiles, but listswf reports ERROR reading.
I suppose that if you have HAVE_LIBZ defined this won't
happen.

> > Note that I was looking at it because I could not
> > handle to compile that actionscript test on top
> > on the TODO list. Basically, listswf was unable to
> > read the compiled snippet. I think that movie.c,
> > asked to compress, did give up (HAVE_ZLIB is
> > not defined) and makeswf failed to catch the error.
> 
> Not sure what to do here. :)

Could you check for requested compressed level
*before* writing anything to disk, OR write
uncompressed even when asked not to, maybe writing
something on the warning channel (do we have a warning
channel?)

--strk;