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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id DD5B53858D1E for ; Wed, 29 Mar 2023 19:14:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD5B53858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680117288; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Id9gbeirqGXYnS3L+D7n4/ugcCkbcI0zqadYvM7IXd0=; b=FRGcZk0/r/wZ5uU/H04Msm/BP0oiquTM0z8a6vKpCptvxhSSs82cQp/Nvz2YNEJ4yUyk4+ 6n8Jd9etIvQttVOilpIsCo0MEfyOmyvSECDXr7f6JGeO6+tvo1AsldMoUxK116blJgUbHO 5Yj+R/NTuHS+48wXpPuBYh5iP731a4o= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-673-TZLm3u0aNfWTRB8etvyn-A-1; Wed, 29 Mar 2023 15:14:45 -0400 X-MC-Unique: TZLm3u0aNfWTRB8etvyn-A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AE008884623; Wed, 29 Mar 2023 19:14:44 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9EABB2027040; Wed, 29 Mar 2023 19:14:44 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1phbFr-0002F7-SZ; Wed, 29 Mar 2023 15:14:43 -0400 Date: Wed, 29 Mar 2023 15:14:43 -0400 From: "Frank Ch. Eigler" To: lilydjwg Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T Message-ID: <20230329191443.GB30778@redhat.com> References: <20230329150237.896092-1-lilydjwg@gmail.com> <20230329150237.896092-2-lilydjwg@gmail.com> MIME-Version: 1.0 In-Reply-To: <20230329150237.896092-2-lilydjwg@gmail.com> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi - > x-debuginfod-size is the actual file size, but CURLINFO_SIZE_DOWNLOAD_T > is transferred size, i.e. the gzipped one if gzip is on. > Let's count written data and use that if and only if x-debuginfod-size > is used. Hey, great idea actually tallying up writes in the callback function. (We need to take care to clear that counter, in case of client object reuse.) Also, can you think of some reason not to just use that value at all times, i.e., without any of that "if and only if ..." business? - FChE