From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96672 invoked by alias); 30 Jul 2018 16:30:47 -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 96041 invoked by uid 89); 30 Jul 2018 16:30:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Jul 2018 16:30:41 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A73DE3001770; Mon, 30 Jul 2018 16:30:39 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-71.ams2.redhat.com [10.36.117.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1FDA600C7; Mon, 30 Jul 2018 16:30:38 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w6UGUZU4026528; Mon, 30 Jul 2018 18:30:36 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w6UGUX3p026527; Mon, 30 Jul 2018 18:30:33 +0200 Date: Mon, 30 Jul 2018 16:30:00 -0000 From: Jakub Jelinek To: Bernd Edlinger Cc: Joseph Myers , 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 Message-ID: <20180730163033.GA17988@tucnak> Reply-To: Jakub Jelinek References: <20180730155724.GZ17988@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg01860.txt.bz2 On Mon, Jul 30, 2018 at 04:28:50PM +0000, Bernd Edlinger wrote: > >>> 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. > > > > To complicate things a bit more STRING_CST that are created by the Ada FE > for the purpose of ASM constraints, do not contain a NUL character. > That is in TREE_STRING_LENGTH, there is of course always another NUL char > after the payload. Likewise for C __attribute__ values. If there is a NUL at TREE_STRING_POINTER (x) + TREE_STRING_LENGTH (x), that is ok. Jakub