From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18647 invoked by alias); 23 Oct 2009 10:08:19 -0000 Received: (qmail 18639 invoked by uid 22791); 23 Oct 2009 10:08:19 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_JMF_BL,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Oct 2009 10:08:14 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KRY00D00P3UOQ00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 23 Oct 2009 12:08:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.77.20]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KRY009L3PHC4CJ0@a-mtaout22.012.net.il>; Fri, 23 Oct 2009 12:08:01 +0200 (IST) Date: Fri, 23 Oct 2009 10:08:00 -0000 From: Eli Zaretskii Subject: Re: [RFA, 3 of 3] save/restore process record, part 3 (save/restore) In-reply-to: <006001ca53be$25d1ab70$71750250$@u-strasbg.fr> To: Pierre Muller Cc: ppluzhnikov@google.com, msnyder@vmware.com, teawater@gmail.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <837humh1bn.fsf@gnu.org> References: <4AD91D72.1030802@vmware.com> <4ADE1612.9040708@vmware.com> <4ADE167F.2020309@vmware.com> <4AE0B40B.5020802@vmware.com> <8ac60eac0910221340y2ad104fo5e4229f017957a5b@mail.gmail.com> <4AE0C669.5020001@vmware.com> <8ac60eac0910221425q63b78a7cnb92b0ddf1c8f5e61@mail.gmail.com> <8ac60eac0910221745t3ef6eb56ra6609086ad07f23@mail.gmail.com> <8ac60eac0910221803p2b45453bu17473aa7e9453a60@mail.gmail.com> <006001ca53be$25d1ab70$71750250$@u-strasbg.fr> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00565.txt.bz2 > From: "Pierre Muller" > Cc: "'Hui Zhu'" , "'Eli Zaretskii'" , > > Date: Fri, 23 Oct 2009 10:52:27 +0200 > > Furthermore, there is a '%ll' rule > in ARI that states that: > Do not use printf("%ll"), instead use printf("%s",phex()) to dump a `long > long' value > Shouldn't this also concern '%lu'? There is a difference: %lu is defined by C89, while %ll is only codified by C9X. GDB does not yet require a C9X compiler. > Do we really need long for sizeof function returns? > Are there any types (use in record.c) for which > sizeof would not fit into a regular "unsigned int" ? sizeof returns a value of the type `size_t'. On a 64-bit host, size_t is typically a 64-bit data type, and so is `unsigned long'. (64-bit Windows is an exception, because it uses a different programming model.)