The idiom scalar(%hash) seems similar to scalar(@array), and in fact
is in current versions of Perl. However, in older versions of Perl,
the former is totally useless:
Prior to Perl 5.25 the value returned was a string consisting
of the number of used buckets and the number of allocated
buckets, separated by a slash. This is pretty much useful only
to find out whether Perl's internal hashing algorithm is
performing poorly on your data set. For example, you stick
10,000 things in a hash, but evaluating %HASH in scalar context
reveals "1/16", which means only one out of sixteen buckets has
been touched, and presumably contains all 10,000 of your items.
This isn't supposed to happen.
As of Perl 5.25 the return was changed to be the count of keys
in the hash. If you need access to the old behavior you can use
"Hash::Util::bucket_ratio()" instead.
Use scalar(keys %hash) instead.
Reported-by: Orkan Sezer <sezeroz@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Clean up some perl warnings, some of which were legitimate (apparently
undef doesn't actually take a list of arguments, a common enough
mistake that it is mentioned in the man page!, and a list of variables
after "my" can be cantankerous), and some of which were nuisance but
were easy enough to clean up.
Maybe this can resolve the problems with very old version of Perl?
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Have warnings.pl give a warning(!) message if a warning definition is
found to be duplicated, including the location of both
definitions. Much better than silently creating bogus output.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
It is extremely desirable to allow the user fine-grained control of
warnings, but this has been complicated by the fact that a warning
class has had to be defined in no less than three places (error.h,
error.c, nasmdoc.src) before it can be used in source code. Instead,
use a script to define these via magic comments at the point of use.
This hopefully will encourage creating new classes as needed.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This will make it a lot easier to create new warning categories by
inserting a block comment directly in the source code near where the
warning is used.
This block comment should look like:
/*
*!warning-name {on|off|err} this is a warning
*!
*! needs a help text.
*/
nasm_warnf(WARN_WARNING_NAME, ...);
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
