From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8109 invoked by alias); 19 Dec 2013 12:41:31 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 8091 invoked by uid 89); 19 Dec 2013 12:41:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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; Thu, 19 Dec 2013 12:41:30 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBJCfP0q010751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Dec 2013 07:41:25 -0500 Received: from [10.36.7.45] (vpn1-7-45.ams2.redhat.com [10.36.7.45]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBJCfJnk018925 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 07:41:21 -0500 Message-ID: <52B2E8C4.3080208@redhat.com> Date: Thu, 19 Dec 2013 12:41:00 -0000 From: nick clifton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22.1 MIME-Version: 1.0 To: Pierre Muller , "'Pedro Alves'" , "'asmwarrior'" CC: "'GDB Development'" , "'Binutils Development'" Subject: Re: [RFC-v2] BFD MinGW/Cygwin build error in bfd/peiXXgen.c References: <52B17083.7040404@gmail.com> <52B1738D.4010409@redhat.com> <002101cefbf1$7554b9a0$5ffe2ce0$@muller@ics-cnrs.unistra.fr> <52B1E03E.9010002@redhat.com> <006c01cefcaf$bec215b0$3c464110$@muller@ics-cnrs.unistra.fr> In-Reply-To: <006c01cefcaf$bec215b0$3c464110$@muller@ics-cnrs.unistra.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00062.txt.bz2 Hi Pierre, > 2) In GDB coding rules, we are not allowed to mix code and declaration. > The declaration of res after handling the ! is_name part > does not follow this rule. > Isn't that rule also used for Binutils project? Doh - this is my bad. The rule *is* followed in the Binutils project and I should have caught this before checking in the patch. I blame the GCC project - ever since they switched over to using C++ I have been developing "bad" C coding habits. > I moved the declaration of astring, alen, bstring and blen to > the start of the function. It does introduce a penalty, in the sense that > those variables are set even though this is not useful if is_name is false. I do not see this as a problem. I am much more interested in clean code than in highly optimized, but harder to read code. > Another silly coding style question: Should there by a space > between the address operator "&" and the variable or expression following? *sigh* There is no strict rule on this subject. Most people omit the space, I include it. I feel that since we separate other operators from their arguments we should do the same with &. I feel the same way about the asterisk operator too, but not many people agree with me on that one either. > 3) I was wondering why the Windows case started at astring + 2, > but I couldn't find any valid reason, so that I changed it to > compare the strings from the first position. Doh - I was confused by the length field which I thought was included in my string pointer. > Finally, I also have a question regarding the codepage field. > According to Windows PE resources can use any codepage. > Is the new code restricted to UNICODE only? > If not, shouldn't the rsrc_cmp code also depend on whether > 16-bit Windows UNICODE is used or any other page code? I have no idea. :-( I am not an expert on this subject. According to the "Microsoft Portable Executable and Common Object File Format Specification Revision 8.3 – February 6, 2013" which has been my guide for this work, the codepage field is: The code page that is used to decode code point values within the resource data. Typically, the code page would be the Unicode code page. But Resource Directory Strings are: Offset Size Field Description 0 2 Length The size of the string, not including length field itself. 2 variable Unicode The variable-length Unicode string data, String word-aligned. Ie - the strings are explicitly encoded in Unicode. I think that the codepage field in a resource entry only applies to non-resource-string data. > 2013-12-19 Pierre Muller > > peXXigen.c (u16_mbtouc): Avoid unused function warning by excluding if > __CYGWIN__ or __MINGW32__ macro is defined. > (rsrc_cmp): Fix Windows host version and version without wchar header. > [__CYGWIN__, __MINGW32__]: Introduce rsrccmp macro. Thanks - I have applied this patch. Cheers Nick