On Apr 18, 2012, at 10:25 AM, Jim Preston wrote:
> Too many times error messages are meaningless to almost anyone who is not
> part of the build team.
That's may well be true in general, but ClamAV is open source: you've got the
source code and build infrastructure available to inspect and determine the
reason for an error message. In other words, if you're running ./configure,
welcome to the build team.
> In this particular instance, that is not the case, due to the big catch-all
> content of the message in combination with the configure options. I agree
> with Jasowicz that it would be more meaningful if it specifically pointed out
> that the warning message was generated by the --disable-zlib-vcheck option
> and even better if it included the results of the option check (if failing
> due to incorrect/bad version). ./configure does this if the build actually
> fails (e.g. missing a dependency).
Wouldn't one expect a flag named "--disable-zlib-vcheck" to disable version
checking of zlib?
Alternatively, don't use that flag and ClamAV's configure tests will do what
you ask for. See the following section:
# Check whether --enable-zlib-vcheck was given.
if test "${enable_zlib_vcheck+set}" = set; then :
enableval=$enable_zlib_vcheck; zlib_check=$enableval
else
zlib_check="yes"
fi
if test ! -f "$ZLIB_HOME/include/zlib.h"
then
as_fn_error $? "Please install zlib and zlib-devel packages" "$LINENO" 5
else
vuln=`grep "ZLIB_VERSION \"1.2.0" $ZLIB_HOME/include/zlib.h`
if test -z "$vuln"; then
vuln=`grep "ZLIB_VERSION \"1.2.1" $ZLIB_HOME/include/zlib.h`
fi
if test -n "$vuln"; then
if test "$zlib_check" = "yes"; then
as_fn_error $? "The installed zlib version may contain a security
bug. Please upgrade to 1.2.2 or later: http://www.zlib.net. You\
can omit this check with --disable-zlib-vcheck but DO NOT REPORT any stability
issues then!" "$LINENO" 5
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: ****** This
ClamAV installation may be linked against" >&5
$as_echo "$as_me: WARNING: ****** This ClamAV installation may be linked
against" >&2;}
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: ****** a broken
zlib version. Please DO NOT report any" >&5
$as_echo "$as_me: WARNING: ****** a broken zlib version. Please DO NOT report
any" >&2;}
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: ****** stability
problems to the ClamAV developers!" >&5
$as_echo "$as_me: WARNING: ****** stability problems to the ClamAV developers!"
>&2;}
fi
fi
> I am a part-time C++, C#, VB, command line script programmer and fully
> realize that the cost of programming will go up incrementally with the
> programmatic handling of errors to give precise granular messages . But in
> response to that argument I generally respond with "If you are bothering to
> capture an error, might as well make the error message mean something. If
> not, just let it crash without any message rather than displaying meaningless
> messages".
Heh. CMU used freshman programming class to weed out prospective comp sci
students. One of the ways they did so was to fail any student program which
crashed. You weren't required to provide a Shakespearean sonnet of an error
message, but you were expected to catch all possible exceptions and log
something rather than crashing.
> If a log is being generated, putting the details in the log, stating the log
> contains the details AND giving the name and location of the log is a good
> SOP starting point. For example one of my pet peeves is the following error
> message "An error has occurred". I have to work in the MS Windows world and
> sadly this is a typical error message in the Wonderful World of Windows (and
> I used to think WWW stood for something else.....). The programmer should not
> have bothered displaying a message if that is all they are going to say about
> it. It does not tell the user anything useful to try and solve the problem.
I happen to be of the opinion that ClamAV's configure goes well out of it's way
to clearly identify potentially buggy libraries and provide clear references to
CVE #s, GCC PRs, and so forth. If you have a different opinion, well, you're
welcome to update the messages being displayed by ./configure and provide a
diff for the ClamAV developers to consider adopting, if they feel your changes
offer more clarity.
Regards,
--
-Chuck
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
