Incompatible clipboard format between 32bit and 64bit cygwin

[Brian Inglis]

On 2021-09-28 00:19, Takashi Yano via Cygwin wrote:
> 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 didn't think any of those types varied by architecture, given the same 
underlying file systems are supported, except the trailing long 
st_spare4[2]; if it does, your proposal is better.

> 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;

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]