From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id EAB963858D28 for ; Wed, 8 Dec 2021 06:30:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EAB963858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 1B86Un9h018724 for ; Tue, 7 Dec 2021 22:30:49 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdmxUB0u; Tue Dec 7 22:30:43 2021 Subject: Re: [PATCH v2] Cygwin: clipboard: Fix a bug in read(). To: cygwin-patches@cygwin.com References: <20211207140006.912-1-takashi.yano@nifty.ne.jp> From: Mark Geisert Message-ID: <549e1dea-5545-50c5-fc1f-79c2c4982e8c@maxrnd.com> Date: Tue, 7 Dec 2021 22:30:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00, BODY_8BITS, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-patches@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component patch submission and discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 06:30:53 -0000 Brian Inglis wrote: > On 2021-12-07 13:18, Thomas Wolff wrote: >> >> Am 07.12.2021 um 15:23 schrieb Corinna Vinschen: >>> On Dec  7 23:00, Takashi Yano wrote: >>>> - Fix a bug in fhandler_dev_clipboard::read() that the second read >>>>    fails with 'Bad address'. >>>> >>>> Addresses: >>>>    https://cygwin.com/pipermail/cygwin/2021-December/250141.html >>>> --- >>>>   winsup/cygwin/fhandler_clipboard.cc | 2 +- >>>>   winsup/cygwin/release/3.3.4         | 6 ++++++ >>>>   2 files changed, 7 insertions(+), 1 deletion(-) >>>>   create mode 100644 winsup/cygwin/release/3.3.4 >>>> >>>> diff --git a/winsup/cygwin/fhandler_clipboard.cc >>>> b/winsup/cygwin/fhandler_clipboard.cc >>>> index 0b87dd352..ae10228a7 100644 >>>> --- a/winsup/cygwin/fhandler_clipboard.cc >>>> +++ b/winsup/cygwin/fhandler_clipboard.cc >>>> @@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len) >>>>         if (pos < (off_t) clipbuf->cb_size) >>>>       { >>>>         ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len; >>>> -      memcpy (ptr, &clipbuf[1] + pos , ret); >>>> +      memcpy (ptr, (char *) &clipbuf[1] + pos, ret); > >>> I'm always cringing a bit when I see this kind of expression. Personally >>> I think (ptr + offset) is easier to read than &ptr[offset], but of course >>> that's just me.  If you agree, would it be ok to change the above to >>> >>>    (char *) (clipbuf + 1) >>> >>> while you're at it?  If you like the ampersand expression more, it's ok, >>> too, of course.  Please push. > >> In this specific case I think it's actually more confusing because of the type >> mangling that's intended in the clipbuf. >> At quick glance, it looks a bit as if the following were meant: >> >>    (char *) clipbuf + 1 >> >> I'd even make it clearer like >> >> +      memcpy (ptr, ((char *) &clipbuf[1]) + pos, ret); >> or even >> +      memcpy (ptr, ((char *) (&clipbuf[1])) + pos, ret); > > If the intent is to address: > >     clipbuf + pos + 1 > > use either that or: > >     &clipbuf[pos + 1] > > to avoid obscuring the intent, > and add comments to make it clearer! Boy am I kicking myself for screwing up the original here and opening this can of worms. Brian, you'd be correct if clipbuf was (char *) like anything-buf often is. But here it's a struct defining the initial part of a dynamic char buffer. So my original &clipbuf[1] to mean "just after the defining struct" was OK. But the code needed a ptr to some char offset after that and &clipbuf[1] + pos was wrong. Casting the left term to (char *) would fix it. But I like Corinna's choice of (char *) (clipbuf + 1) to be most elegant and clear of all. Now enclose that in parens and append the char offset so the new expression is ((char *) (clipbuf + 1)) + pos and all should be golden. I don't think extra commentary is needed in code. (I think.) ..mark