From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16777 invoked by alias); 30 Jul 2018 16:01:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16694 invoked by uid 89); 30 Jul 2018 16:01:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Jul 2018 16:01:34 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-03.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1fkAc0-0002da-3B from joseph_myers@mentor.com ; Mon, 30 Jul 2018 09:01:32 -0700 Received: from digraph.polyomino.org.uk (137.202.0.87) by SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 30 Jul 2018 17:01:27 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1fkAbv-0008UR-Ct; Mon, 30 Jul 2018 16:01:27 +0000 Date: Mon, 30 Jul 2018 16:01:00 -0000 From: Joseph Myers To: Jakub Jelinek CC: Bernd Edlinger , Richard Biener , Ian Lance Taylor , GCC Patches , Jeff Law , Martin Sebor Subject: Re: [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c In-Reply-To: <20180730155724.GZ17988@tucnak> Message-ID: References: <20180730155724.GZ17988@tucnak> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-07/txt/msg01855.txt.bz2 On Mon, 30 Jul 2018, Jakub Jelinek wrote: > On Mon, Jul 30, 2018 at 03:52:39PM +0000, Joseph Myers wrote: > > On Mon, 30 Jul 2018, Bernd Edlinger wrote: > > > > > In the moment I would already be happy if all STRING_CSTs would > > > be zero terminated. > > > > generic.texi says they need not be. Making the STRING_CST contain only > > the bytes of the initializer and not the trailing NUL in the C case where > > the trailing NUL does not fit in the object initialized would of course > > mean you get non-NUL-terminated STRING_CSTs for valid C code as well. > > One thing is whether TREE_STRING_LENGTH includes the trailing NUL byte, > that doesn't need to be the case e.g. for the shortened initializers. > The other thing is whether we as a convenience for the compiler's internals > want to waste some memory for the NUL termination; I think we could avoid > some bugs that way. TREE_STRING_LENGTH includes the NUL if it is logically part of the object, but should not if the NUL is purely an implementation convenience. -- Joseph S. Myers joseph@codesourcery.com