bug#53696: Integer overflow on Guix GC size calculation

[Bengt Richter]

Hi Maxime, Ekaitz, et al,

On +2022-02-02 11:05:31 +0100, Maxime Devos wrote:
> Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+0000]:
> > [17592186042897 MiB] deleting 
> > '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'
> 
> For comparison, this is about 16 exbibyte.
> According to <https://en.wikipedia.org/wiki/Byte#Multiple-byte_units>,
> that's more than the global monthly Internet traffic in 2004.
> 
> According to <https://what-if.xkcd.com/31/>, 16 exbibyte would be about
> 17 million solid-state disks.  Even though this ignores deduplication,
> this seems rather expensive. 
> 
> My guess is that the size of a store item was misrecorded somewhere.
> 
> Greetings,
> Maxime.

s/misrecorded/mis-defined-in-record/ ?
Wild guessing follows:

--8<---------------cut here---------------start------------->8---
$ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t 
"~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa1100000 #xa1100000)';
    ffffffffa1100000
            a1100000
          2702180352
--8<---------------cut here---------------end--------------->8---

It looks to me like a 32-bit unsigned int should have been turned to 64-bit 
unsigned long or bigint
but somehow got cast/interpreted as signed, becoming signed 64-bit long,
which then in turn was seen by the print as 64-bit unsigned long.

I don't know, but if records are being used, perhaps some slot integer-widening 
logic
might be involved? Or a mis-defined int slot that should have been long to 
accomodate
big > 31-bit  positive integers?

Just guessing wildly -- I think I saw something about records and defining 
their fields
as fixed C ints or longs.

-- 
Regards,
Bengt Richter