Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Jan 2001 07:00:10 -0800 (PST)
From:      "Dmitry Kazarov" <kazarov@izmiran.rssi.ru>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: bin/24732: cmp can not compare files lager 2GB but smaller 4GB
Message-ID:  <200101301500.f0UF0Ad04989@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/24732; it has been noted by GNATS.

From: "Dmitry Kazarov" <kazarov@izmiran.rssi.ru>
To: "Bruce Evans" <bde@zeta.org.au>
Cc: <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: bin/24732: cmp can not compare files lager 2GB but smaller 4GB
Date: Tue, 30 Jan 2001 17:59:23 +0300

 > > So constant should be decreased to 1GB
 >
 > This is rather machine-dependent, and probably too large to be optimal
 > anyway.
 >
 > To fix the machine-dependencies, I think cmp should just try to mmap
 > both files and fall back to c_special() if this fails.  Note that
 > the current check against SIZE_T_MAX is just to prevent overflow,
 > but it is broken in several ways:
 > (1) It SIZE_T_MAX with MIN(len1, len2), but it needs to compare with
 >     MAX(len1, len2) to prevent overflow when the lengths are cast to
 >     size_t.
 > (2) It needs comapare SIZE_T_MAX with
 >     MAX(len1 + skip1 % pagesize, len2 + skip2 % pagesize) to prevent
 >     overflow when the adjusted lengths are passed to mmap().
 > The casts in (1) are bogus anyway.  They are unnecessary if a prototype
 > for mmap() is in scope and are in the wrong place otherwise (the whole
 > adjusted lengths should be cast).
 
 Hi, Bruce,
 Sorry, I do not understand why compare MAX(...) to SIZE_T_MAX.
 IMHO, mmap maps the file into process memory so both files together should
 fit into process accessible address space which is less then SIZE_T_MAX (my
 expirements with cmp showed that is about 2430MB, on Solaris 2.4 it was 2GB
 only).
 So it's nessesary to compare (len1+skip1%pagesize + len2+skip2%pagesize) to
 2430MB (for my system).
 Cause, reverting to c_special on mmap failure could be a better way but,
 IMHO, the best solution would be proposal of Poul-Henning Kamp
 <phk@FreeBSD.org> ( http://www.freebsd.org/cgi/query-pr.cgi?pr=18589 ):
 "Add a loop around the mmap/compare operation which operates on some
 moderate amount of data each iteration."
 
 Sincerely Yours
 Dmitry
 
 
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101301500.f0UF0Ad04989>