X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F31EA3858426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1632810055; bh=zz2vlXlE0VxT5U5aq/krBhbln12KkAnLuSxaEBzY698=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JAcAf3msbRPxm6ONAUvYLb3MuihxTbrmkgSqd0herc1hXlAvQXPaVJpom9kEMU5IX YhDdP8SMLLAfl6WTaFcmP3kEo2KCR/IJcwCt0u4BUh+2gcD6AJtOTwXRI7MzMjgArj 9la32IfkTLFMKbx5oaYy3kjBOjnm9/mEH28prjCY= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B3F5C3858C2C DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 18S6JOVD027937 X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 28 Sep 2021 15:19:36 +0900 To: cygwin AT cygwin DOT com Subject: Re: Incompatible clipboard format between 32bit and 64bit cygwin Message-Id: <20210928151936.2e644c2ebc717dc367e63003@nifty.ne.jp> In-Reply-To: <731c8611-4ed2-29fd-0b9c-33e221d6451e@SystematicSw.ab.ca> References: <20210926103325 DOT 5c17eb11c3c8a56c377199a8 AT nifty DOT ne DOT jp> <584f536c-b108-b562-b940-798ec2847c68 AT maxrnd DOT com> <0b13b9ac-583f-ab72-4202-f8b187946d93 AT towo DOT net> <498f0cfb-c6c1-cb61-2e88-fcb9ce61f4d4 AT maxrnd DOT com> <731c8611-4ed2-29fd-0b9c-33e221d6451e AT SystematicSw DOT ab DOT ca> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 18S6KtMD006073 On Mon, 27 Sep 2021 23:22:30 -0600 Brian Inglis wrote: > On 2021-09-27 22:49, Mark Geisert wrote: > > Hi Thomas, > > > > Thomas Wolff wrote: > >> > >> Am 26.09.2021 um 20:37 schrieb Thomas Wolff: > >>> > >>> Am 26.09.2021 um 11:50 schrieb Mark Geisert: > >>>> Hi Takashi, > >>>> > >>>> Takashi Yano via Cygwin wrote: > >>>>> I noticed that cygwin clipboard is not compatible > >>>>> between 32bit and 64bit cygwin. > >>>>> > >>>>> If I run 'echo AAAAAAAA > /dev/clipboard' in 32bit cygwin, > >>>>> and run 'cat /dev/clipboard' in 64bit cygwin, this result in > >>>>> cat: /dev/clipboard: Bad address > >>>>> > >>>>> This is because the structure > >>>>> typedef struct > >>>>> { > >>>>>    timestruc_t   timestamp; > >>>>>    size_t    len; > >>>>>    char      data[1]; > >>>>> } cygcb_t; > >>>>> defined in fhandler_clipboard.cc has different size. > >>>>> > >>>>> Is this the known issue? > >>>> > >>>> I doubt anybody has ever tried what you did. > >>> I have and it failed; I just didn't find it important enough to > >>> report it here... Thanks for the plan to fix it. > >>> > >>>> I have been testing getclip and putclip between 32- and 64-bit > >>>> environments, but neglected to test Cygwin-internal clipboard format > >>>> that prepends cygcb_t to the user-supplied data. > >> As we're at it, what's the purpose of a cygwin-internal clipboard > >> format at all? > >> Copy/paste between 32bit/64bit mintty works; mintty uses Windows > >> CF_UNICODETEXT clipboard format. > > > > The cygwin-internal clipboard format records a timestamp and content > > length when Cygwin (or putclip) updates the clipboard contents.  This > > allows 'stat' and fstat() to show something sensible for > > /dev/clipboard.  The latter feature went into Cygwin 1.7.13. > > > > Other than that, not much difference to CF_UNICODETEXT ;-). > > Would it perhaps make sense to include struct stat with appropriate > entries rather than a couple of adhoc members unrelated to much else? struct stat also has different size between 32 and 64 bit environment, therefore, it does not resolve the issue. I imagine using structure such as typedef struct { struct { int64_t tv_sec; int64_t tv_nsec; } timestamp; int64_t len; char data[1]; } cygcb_t; rather than typedef struct { struct timespec timestamp; size_t len; char data[1]; } cygcb_t; -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple