From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id Tt6BI4xHUV8hHAAA0tVLHw (envelope-from ) for ; Thu, 03 Sep 2020 19:44:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id aPj4HoxHUV9NEwAAbx9fmQ (envelope-from ) for ; Thu, 03 Sep 2020 19:44:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C84489406B8 for ; Thu, 3 Sep 2020 19:44:11 +0000 (UTC) Received: from localhost ([::1]:42658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDv9V-0006vR-Vl for larch@yhetil.org; Thu, 03 Sep 2020 15:44:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60810) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDv9O-0006tm-NG for bug-guix@gnu.org; Thu, 03 Sep 2020 15:44:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52939) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kDv9O-0003Fz-Dg for bug-guix@gnu.org; Thu, 03 Sep 2020 15:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kDv9O-0002OK-AK for bug-guix@gnu.org; Thu, 03 Sep 2020 15:44:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#38958: Timestamp out of range; substituting 2514-05-30 01:53:03.999999999 Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 03 Sep 2020 19:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38958 X-GNU-PR-Package: guix X-GNU-PR-Keywords: moreinfo To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , 38958@debbugs.gnu.org Received: via spool by 38958-submit@debbugs.gnu.org id=B38958.15991621999134 (code B ref 38958); Thu, 03 Sep 2020 19:44:02 +0000 Received: (at 38958) by debbugs.gnu.org; 3 Sep 2020 19:43:19 +0000 Received: from localhost ([127.0.0.1]:36252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDv8g-0002NF-RL for submit@debbugs.gnu.org; Thu, 03 Sep 2020 15:43:19 -0400 Received: from world.peace.net ([64.112.178.59]:52834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDv8f-0002N0-Ps for 38958@debbugs.gnu.org; Thu, 03 Sep 2020 15:43:18 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kDv8Z-0006Sx-Ux; Thu, 03 Sep 2020 15:43:12 -0400 From: Mark H Weaver In-Reply-To: <87lfhr1bra.fsf@gnu.org> References: <87lfhr1bra.fsf@gnu.org> Date: Thu, 03 Sep 2020 15:42:02 -0400 Message-ID: <87y2lq3avu.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: XQ8kniaUf0dW Hi, Ludovic Court=C3=A8s writes: > The GNU=C2=A0make warnings come from this impenetrable function: > > --8<---------------cut here---------------start------------->8--- > FILE_TIMESTAMP > file_timestamp_cons (const char *fname, time_t stamp, long int ns) > { > int offset =3D ORDINARY_MTIME_MIN + (FILE_TIMESTAMP_HI_RES ? ns : 0); > FILE_TIMESTAMP s =3D stamp; > FILE_TIMESTAMP product =3D (FILE_TIMESTAMP) s << FILE_TIMESTAMP_LO_BITS; > FILE_TIMESTAMP ts =3D product + offset; > > if (! (s <=3D FILE_TIMESTAMP_S (ORDINARY_MTIME_MAX) > && product <=3D ts && ts <=3D ORDINARY_MTIME_MAX)) > { > char buf[FILE_TIMESTAMP_PRINT_LEN_BOUND + 1]; > const char *f =3D fname ? fname : _("Current time"); > ts =3D s <=3D OLD_MTIME ? ORDINARY_MTIME_MIN : ORDINARY_MTIME_MAX; > file_timestamp_sprintf (buf, ts); > OSS (error, NILF, > _("%s: Timestamp out of range; substituting %s"), f, buf); > } > > return ts; > } > --8<---------------cut here---------------end--------------->8--- > > What=E2=80=99s OLD_MTIME? > > --8<---------------cut here---------------start------------->8--- > /* The file does not exist, and we assume that it is older than any > actual file. */ > #define OLD_MTIME 2 > > /* The smallest and largest ordinary timestamps. */ > #define ORDINARY_MTIME_MIN (OLD_MTIME + 1) > --8<---------------cut here---------------end--------------->8--- > > That would mean that any file with mtime < 3 is considered bogus, but > then, why wouldn=E2=80=99t things fail on other machines as well? I spent a bit of time looking at the relevant code in GNU Make. The special MTIME values of 0, 1, and 2 seem to apply only to GNU Make's *internal* representation of the timestamp. 'file_timestamp_cons', which converts a standard POSIX time to the internal representation, seems to properly handle times near the POSIX epoch by adding ORDINARY_MTIME_MIN (via 'offset') to the POSIX time, after multiplying it by 2^30 (if FILE_TIMESTAMP_HI_RES is enabled). > I=E2=80=99m looking for ideas! :-) Note that the date printed in the warning (ORDINARY_MTIME_MAX), represented as a POSIX time (seconds past the epoch), is precisely 2^34 seconds minus one nanosecond. The problem doesn't seem to be that 'stamp' is too small, because if it were, then the following line in 'file_timestamp_cons', ts =3D s <=3D OLD_MTIME ? ORDINARY_MTIME_MIN : ORDINARY_MTIME_MAX; would substitute ORDINARY_MTIME_MIN, which is close to the POSIX epoch, and the warning message would print a time near 1970, instead of one near 2514 (ORDINARY_MTIME_MAX). Rather, it appears that the 'stamp' passed into 'file_timestamp_cons' was close to or larger than 2^34, which is approximately the largest timestamp that GNU make supports when FILE_TIMESTAMP is 64 bits and FILE_TIMESTAMP_HI_RES is enabled. My guess is that maybe our near-zero timestamps are somewhere being adjusted downwards by a timezone conversion, using an unsigned integer type, causing them to wrap around to near the maximum value of that type. Note that although 'stamp' usually comes from a file 'mtime' as returned by stat(2), it can also come from an 'ar' archive member. In make-4.3/src/remake.c, 'f_mtime' includes the following code: --8<---------------cut here---------------start------------->8--- member_date =3D ar_member_date (file->hname); mtime =3D (member_date =3D=3D (time_t) -1 ? NONEXISTENT_MTIME : file_timestamp_cons (file->hname, member_date, 0)); --8<---------------cut here---------------end--------------->8--- Mark