From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18922 invoked by alias); 10 Apr 2012 14:30:14 -0000 Received: (qmail 18910 invoked by uid 22791); 10 Apr 2012 14:30:13 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from outdoor.onevision.de (HELO outdoor.onevision.de) (212.77.172.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 14:29:58 +0000 Received: from sanders.onevision.de (moonrace [212.77.172.62]) by outdoor.onevision.de (8.14.3/8.13.7/ROSCH/DDB) with ESMTP id q3AEThQn021835; Tue, 10 Apr 2012 16:29:48 +0200 Received: from [192.168.5.32] ([192.168.5.32]) by sanders.onevision.de (Lotus Domino Release 8.5.1FP3) with ESMTP id 2012041016293798-16332 ; Tue, 10 Apr 2012 16:29:37 +0200 Message-ID: <4F8443D1.9080105@onevision.com> Date: Tue, 10 Apr 2012 14:30:00 -0000 From: Roland Schwingel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: insight@sourceware.org, Patrick.Monnerat@datasphere.ch Subject: Re: [PATCH] print format does not match argument type Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2012-q2/txt/msg00004.txt.bz2 Hi Patrick, insight-owner@sourceware.org wrote on 05.04.2012 18:34:27: > In gdb/gdbtk/generic/gdbtk-register.c, 2 statements try to use a print > format of "%lx" for a size_t argument. The correctness of such > statements is architecture dependent. If warnings are treated as > errors,the compilation fails. Which warnings do you get on which platform? The casts to size_t where introduced by myself some days ago. Previously they where casted to long. The TYPE_FIELD_TYPE macro returns a pointer to a struct type. Treating this as (unsigned) long is pretty correct on *nix style systems but not on windows. On 64bit windows a long is still 4 bytes long, so the downcasted value is simply wrong. Roland