From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 22773386F407 for ; Mon, 23 Nov 2020 20:02:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 22773386F407 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-135-koEu2JqeMEadAvHaDaKDVw-1; Mon, 23 Nov 2020 15:02:31 -0500 X-MC-Unique: koEu2JqeMEadAvHaDaKDVw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CC1078030A5; Mon, 23 Nov 2020 20:02:29 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-152.phx2.redhat.com [10.3.113.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F7CD5C1BB; Mon, 23 Nov 2020 20:02:28 +0000 (UTC) Subject: Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding To: JeanHeyd Meneide , Bernhard Reutner-Fischer Cc: JeanHeyd Meneide via Gcc-patches , Joseph Myers References: <9F4AE870-69D6-4152-A558-61F0A3F61441@gmail.com> From: Jeff Law Message-ID: <7dd57cee-bc5b-d68c-ca89-d70bc7ebbc7f@redhat.com> Date: Mon, 23 Nov 2020 13:02:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 20:02:35 -0000 On 10/9/20 6:39 AM, JeanHeyd Meneide via Gcc-patches wrote: > Hello, > >> Typo: comple-time >> >>> 2020-10-08 JeanHeyd "ThePhD" Meneide >>> >>> * gcc/c-family/c-cppbuiltin.c: Add predefined macro >>> definitions for charsets >> I think you should put the macro names in braces after the filename and drop the trailing "for charsets". > Can do! > >>> * gcc/doc/cpp.texi: Document new predefined macro. >>> * gcc/testsuite/c-c++-common/cpp/wide-narrow-predef-macros.c (new): >> I think you should drop "(new)" above. >> thanks, > I saw that in previous changelogs, but I can change it! Fixed up > the typos, too. > > Sincerely, > JeanHeyd > > 2020-10-09 JeanHeyd "ThePhD" Meneide > > * gcc/c-family/c-cppbuiltin.c: Add predefined > {__GNUC_EXECUTION_CHARSET_NAME} and > {__GNUC_WIDE_EXECUTION_CHARSET_NAME} macros > * gcc/doc/cpp.texi: Document above new predefined macros > * gcc/testsuite/c-c++-common/cpp/wide-narrow-predef-macros.c: > New test for macro definitions to always exist and be strings > * libcpp/include/cpplib.h: Add functions declarations for > retrieving charset names > * libcpp/directives.c: Add function definitions to retrieve charset > names > * libcpp/internal.h: Add to/from name preservations > > encoding_names.patch.txt > [ ... ] > diff --git a/libcpp/charset.c b/libcpp/charset.c > index 28b81c9c864..3e5578b1390 100644 > --- a/libcpp/charset.c > +++ b/libcpp/charset.c > @@ -638,6 +638,9 @@ init_iconv_desc (cpp_reader *pfile, const char *to, const char *from) > char *pair; > size_t i; > > + ret.to = to; > + ret.from = from; > + AFAICT ret.from is never used.  Is there a reason why you're saving it? You use a getter function to retrieve the value of ret.to, which is fine.  Is there a specific reason why you're not using a setter function to save the value? Otherwise I think this is basically ready to be included. jeff