On 03/11/2020 16:00, Paul Kosinski via clamav-users wrote:
"(don't you love C?)"
I have never understood why the originators of C didn't give integers
explicit widths in bits: their scheme made C code often non-portable.
Because C is intended to be very, very close to the machine
I'm not a big Windows fan, but it sounds like ClamAV regexes are rather
unfriendly to Windows since they don't seem to have an "ignore case"
option (unlike most other regex-using programs).
Assuming that is the case (sic), you might try:
ExcludePath "[Cc]:\\[Ww][Ii][Nn][Dd][Oo][Ww][Ss]"
as a
"(don't you love C?)"
I have never understood why the originators of C didn't give integers
explicit widths in bits: their scheme made C code often non-portable.
When I wrote code in the mid 1990s for the DEC Alpha, ints were 32 bits
while longs were 64 (unlike "standard" C). This made Alpha C
Thanks Pablo,
Just took a look - it seems that image001.gif is missing the final byte, a
value "0x3B" should be at the end of every GIF file. Interestingly firefox
rendered it, though clam didn't like it and 010editor's GIF template also
couldn't handle it. Perhaps this is the sort of issue
I try so send several mails to the list with gifs attached, but none
arrived to the list
I'm sending a link to one gif that everyday is rejected by ClamAV
Link to gif file: http://pablomurillo.com.ar/image001.gif
On 11/2/2020 9:02 PM, Micah Snyder (micasnyd) via clamav-users wrote:
We
I hadn't really looked at the code. You raise a good point.
Changing it isn't super simple. The info.blocks variable is passed through
cli_scandesc_callback() and scan_common() where it's placed into the scan
context. When data is scanned, the amount scanned is divided by
CL_COUNT_PRECISION
Can this really be done? I was looking at the code referred to by G.W.
Haywood, and I see that it uses "info.blocks" and "info.rblocks".
Looking at the definitions in "clamav-0.103.0/clamscan/", I see the
following:
struct s_info {
unsigned int sigs; /* number of signatures */
We disabled the PNG parser because of bugs in the code that need to be fixed.
I'm actively working on the PNG and GIF parsers, and have started testing with
larger sample sets to try to make sure they're more robust. T
he GIF parser seems fairly stable though I'm putting a lot of effort into
I agree. We already have some logic in freshclam to convert bytes to human
readable B / KiB / MiB / GiB format. It should be pretty much a copypaste
effort to improve the data scanned/read output.
-Micah
On 11/2/20, 9:47 AM, "clamav-users on behalf of G.W. Haywood via clamav-users"
Hi
What happened with this ?
Now I'm seeing some errors in GIF files too
On 10/21/2020 2:04 PM, Pablo Murillo wrote:
Ajajaja
I feel better !
ajajaja
Check the mail I sent few minutes ago with more info and more files
(defug, config, the rights pngs, and the real error)
Sorry my english !
Hi there,
On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
... I still think it is a bad message that should be fixed.
+1
If you want to try a very quick and dirty tweak to get more precise
numbers, change the value of
1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
When I first saw this message, I quickly concluded it was a roundoff
behavior. But I still think it is a bad message that should be fixed.
First, most file managers that only display file sizes in "human
readable" form, still display a non-zero size for small files. Second,
it is not logically
12 matches
Mail list logo
