From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from libero.it (smtp-17-i2.italiaonline.it [213.209.12.17]) by sourceware.org (Postfix) with ESMTPS id C73F03858C54 for ; Wed, 27 Apr 2022 09:21:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C73F03858C54 Received: from oxapps-37-171.iol.local ([10.101.8.217]) by smtp-17.iol.local with ESMTPA id jdrlnX5s58sytjdrlnAQcg; Wed, 27 Apr 2022 11:21:45 +0200 x-libjamoibt: 1601 X-CNFS-Analysis: v=2.4 cv=KqWIZUaN c=1 sm=1 tr=0 ts=62690b2a cx=a_exe a=Dy6Kaa9DRUc+pnVf14QIwg==:117 a=DtqkoXZ5MxIA:10 a=IkcTkHD0fZMA:10 a=FDU5-MRIzX4A:10 a=n9Nvxce8AAAA:8 a=9dxmIBhqWFCvGlhFBP8A:9 a=QEXdDO2ut3YA:10 a=V4tbcg9hxeXQX3VEsxKP:22 Date: Wed, 27 Apr 2022 11:21:45 +0200 (CEST) From: Carlo Bramini To: "bzip2-devel@sourceware.org" Message-ID: <800388119.1021596.1651051305973@mail1.libero.it> In-Reply-To: References: <434364370.952076.1650983602854@mail1.libero.it> Subject: Re: Declare bzerrorstrings[] to be a const object. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev39 X-Originating-IP: 93.63.107.146 X-Originating-Client: open-xchange-appsuite x-libjamsun: nn08LwqU5QYyDdWgDBEcVkbyngKuOieJ x-libjamv: fHXXwQyX+44= X-CMAE-Envelope: MS4xfJhUp79WSHCQM5tTKMR8a7JkZ3/uoSMsGg1uMux+OPpgYudFQr7qE8ONSsoUqcuvjFLzsDwhBOT0XHrLKJ3Wj8cfroRXqTONUCHS7+5H1wpWL9QRwGP9 01vyNacOVaGzMoJ9/aiMfr4Y/iryk/A84MqZ+kwfXZOty/BdqSeIvmy7hMGIgsXPRIcsWUckay6plnFmGf+ZTaiSFf+NYXtaejI= X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: bzip2-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bzip2-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2022 09:21:51 -0000 Hello, I compiled BZip2 for an embedded system, to be used in an homebrew project. The platform is an ARM Cortex M4 microcontroller which provides some internal memories, like all other devices with similar purpose: * a FLASH memory, which is usually bigger and it stores the code and constant data of a firmware. * a RAM memory, which is tipically much smaller than the FLASH and it is used for the stack and all data that can change their value during the execution of the program. Since the RAM memory is a limited resource, one of the tasks of the developer is to move all data that won't change their value into the FLASH, not only for security reasons but because it is needed to do so, for maximizing the amount of available RAM. To do so, the developer usually examines a map file to see if some memory could be optimized, especially when using code written by others. So, I gave a look to the map file and I have seen that something could be improved in this way. In this specific case, the bzerrorstrings[] is actually made by two distinct logical objects: 1) the bzerrorstrings[], which holds some pointers to strings. 2) the strings pointed by the bzerrorstrings[]. Actually, you can decide which of these items is a const object: the strings, the bzerrorstrings[] table or both. The attached patch just adds another const attribute for having both items into the read-only area, which seems to be the expected behaviour of that piece of code. It is true that this fix won't improve the memory usage on a system like a PC, however it could be also useful since an exception could be raised if something will accidentally write into a memory expected to be read-only. By looking my map file, I have to say that there are also other things that may be declared as const: blocksort.c: - static Int32 incs[14] bzip2.c - const Char* zSuffix[BZ_N_SUFFIX_PAIRS] - const Char* unzSuffix[BZ_N_SUFFIX_PAIRS] crctable.c - UInt32 BZ2_crc32Table[256] randtable.c - Int32 BZ2_rNums[512] but unfortunately I'm unsure about the code, so the bzerrorstrings[] table was the easiest one for me to understand that it was a safe change. I hope that you will find this report useful. Sincerely, Carlo Bramini. > Il 26/04/2022 21:35 Mark Wielaard ha scritto: > > > Hi, > > On Tue, Apr 26, 2022 at 04:33:22PM +0200, Carlo Bramini via Bzip2-devel wrote: > > by looking the content of the map file, I discovered that bzerrorstrings[] is not const. > > Which map file is this? > > > So, I would like to suggest the tiny change into the attached patch, for declaring both bzerrorstrings[] and the addressed strings as const. > > The patch has been created from the latest sources into the repository with GIT. > > Although the patch seems fine I must admit that I don't fully > understand why it is necessary. Isn't an array (name) not always > constant? You cannot assign anything to an array name since it is a > contant pointer to the first element. Or is that not what this "const" > is about? > > Thanks, > > Mark