From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E57FE3858D37 for ; Mon, 6 Jul 2020 14:14:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E57FE3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 983E21E793; Mon, 6 Jul 2020 10:14:21 -0400 (EDT) Subject: Re: [PATCH v2 2/7] Add "help news" To: Tom Tromey , Christian Biesinger via Gdb-patches References: <20200623132006.15863-1-tom@tromey.com> <20200623132006.15863-3-tom@tromey.com> <875zb2kl6j.fsf@tromey.com> From: Simon Marchi Message-ID: <66512dc6-6498-520d-ae54-51de98db5f06@simark.ca> Date: Mon, 6 Jul 2020 10:14:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <875zb2kl6j.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 14:14:23 -0000 On 2020-07-05 11:59 a.m., Tom Tromey wrote: >>>>>> "Christian" == Christian Biesinger via Gdb-patches writes: > > Christian> On Tue, Jun 23, 2020 at 8:20 AM Tom Tromey wrote: >>> +static void >>> +help_news (struct ui_file *stream) >>> +{ >>> + std::string news_name = std::string (gdb_datadir) + SLASH_STRING + "NEWS"; >>> + gdb_file_up news_file = gdb_fopen_cloexec (news_name.c_str (), "r"); >>> + if (news_file == nullptr) >>> + perror_with_name (_("could not open the NEWS file")); >>> + >>> + char buffer[1024]; >>> + size_t offset = 0; >>> + while (true) >>> + { >>> + size_t nbytes = fread (&buffer[offset], 1, sizeof (buffer) - offset, >>> + news_file.get ()); > > > Christian> Why not use read_entire_file from your other patch? > > The NEWS file seems large-ish, and I figured the normal thing for users > would be to use the pager to view the top, then stop reading. The NEWS file is 281k and contains all NEWS since GDB 4.0 (pre year 2000). So I think it's safe to say that it grows much slower than the available memory on the average computer grows. That amount in memory is minimal compared to what is typically used for reading DWARF information of large-ish programs, and it's just transient use anyway. So I think it's safe to read it all, and preferable if it makes the code simpler. I don't think reading 281k will cause any delay noticeable to the user of "help news". Simon