Re: Incompatible clipboard format between 32bit and 64bit cygwin

[Takashi Yano <takashi.yano@nifty.ne.jp>]

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 <takashi.yano@nifty.ne.jp>