Hi all,

I would call this a bug. Scanning 1 byte is the same as scanning 1 block.

When storing things in blocks is is always important to round up or you
get a false impression of reality.

You can't store 100 bytes in 0 disk sectors of 128 bytes. It is always 1
disk sector.

Can you not just round up by adding (BlockSize - 1) bytes when setting
the block variables ?

Regards
        Mark.

On 03/11/2020 16:07, Paul Kosinski via clamav-users wrote:
> "This is a display problem, not a storage problem."
>
> I disagree. When the counts in info.blocks and info.rblocks are counts
> of 16kb *blocks*, keeping precise track of the reading and scanning of
> small files is impossible, no matter how clever the display code is.
>
>
>
> On Tue, 3 Nov 2020 17:44:18 +1100
> "Gary R. Schmidt" <grschmidt@acm.org> wrote:
>
>> 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
>> architecture, only a step or tow above assembler, or doing the
>> bit-twiddling by hand.
>>
>>> 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 code not
>>> portable to lesser CPUs. On the other hand, when I wrote C on DOS for
>>> the IBM PC in the late 1980s, ints were only 8 bits! It took some time
>>> to figure out why my C-compliant code failed so badly. In spite of all
>>> that, having started programming before C was invented, I can safely
>>> say that C is better than its predecessors for software like ClamAV.
>>>   
>> Uh, not a good example, I've written C code that is still in use on
>> everything from 80286s (yes, Virginia, there are people who keep them
>> alive, not just because they're cheap, sometimes just because they
>> *can*) to DEC Alphas and Power and SPARC64 and PA-RISC, it's just a
>> matter of knowing what you are doing, and sticking to it...
>>
>>> P.S. Good code these days tends to use typedefs defining things like
>>> int32, uint64 etc. A shame the original ClamAV coders didn't do that.
>>>   
>> And none of this has *anything* to do with the original problem - seeing
>> 0 when the value is 0.0000000001, or so.
>>
>> This is a display problem, not a storage problem.  You could declare
>> something as PIC(9999999.99999999999999) and you will still only see 0
>> if you told it to display two decimal places.
>>
>>      Cheers,
>>              Gary    B-)
>
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml