[clamav-users] ClamAV Scan - Data Read vs Data Scanned

[Gary R. Schmidt]

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-)