From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 822191F5AE for ; Fri, 31 Jul 2020 00:31:59 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8C9153857C58; Fri, 31 Jul 2020 00:31:58 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 156373858D35 for ; Fri, 31 Jul 2020 00:31:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 156373858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: 6X1RF5RqdW6H/N1CJKTX31mD1QDhjgEWj0I+G6SPoWHrbwPVkMlY+otqQzzC/FrsZ/VknSFA5+ eUACcCqZzPmdDQ4tOf/nG42YhCH6tT7jMJqFewyvsxokz+9pUgHmdcG5jyUJpVaK9Vudio9vey B2klzFAjadXiF9aaLlOly0aAvn7L2f2nht0jEMIqy3zzH9zCbqS8venA/Ru9mkIcXCbHxK4bSJ PC4L/s0dzi9hcOIR4FedILvVpTFDiVTdoCBnl80rK1bXpOzEzLVqmOzxQznWIuunq/666fd9lx WSs= X-IronPort-AV: E=Sophos;i="5.75,416,1589270400"; d="scan'208";a="51481312" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 30 Jul 2020 16:31:49 -0800 IronPort-SDR: qsbdSpWI2N2knR60U1DsD4acvUT/GH4aDceP+OrEbk2G4OQQESBpC6TDDHoLqBMXTybc3J969X /DNmxULEJ8WZev6JpBVO5UDAfSZbpTgkSTmmPWNltb8yaafREwaLCMFGxOu/n/oIWNTZvTDdUo KlaBP4gFnWEb+tO690X30947fAH9fVEFivN5Yn+GCPH5YSrHTsRT0IGl78GUq/ORy/Vifwu58l UScZqjiOEQitVdVSn4RGrQhbP+CZduKaX/KaNoc1co+zM2yn7CShcqHmnxs45QxgUzNzZmDMME XyE= Date: Fri, 31 Jul 2020 00:31:44 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Adhemerval Zanella Subject: Re: [PATCH 4/5] login: User 64-bit time on struct lastlog In-Reply-To: Message-ID: References: <20200729205117.2925113-1-adhemerval.zanella@linaro.org> <20200729205117.2925113-4-adhemerval.zanella@linaro.org> <87a6zinhvp.fsf@igel.home> <874kppgem1.fsf@oldenburg2.str.redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Thu, 30 Jul 2020, Adhemerval Zanella via Libc-alpha wrote: > The different filename sound slike a strategy and I understand that the idea > would also to use new versions for the utmp/utmpx symbols. What about the > compatibility symbols, should them be built on top of the new ABI and access > the newer files or use the old format and access the old filenames? I suppose that gets into questions about programs explicitly using utmpname. If a program using the old symbol versions called utmpname explicitly with some filename, that's probably the name of a file in the old format. But if it doesn't call utmpname, either you can access the old files in the old format and not get current data, or the new files in the new format and convert. -- Joseph S. Myers joseph@codesourcery.com