Incompatible clipboard format between 32bit and 64bit cygwin

Incompatible clipboard format between 32bit and 64bit cygwin

[Takashi Yano]

Hi all,

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?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

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

[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 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.  So getclip and 
putclip will need fixing as well.

I will submit a Cygwin patch to fix /dev/clipboard usage and a similar patch to 
cygutils for the utilities.

I appreciate your help in uncovering and investigating bugs in clipboard support.
Thanks & Regards,

..mark

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

[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.  So getclip and 
> putclip will need fixing as well.
>
> I will submit a Cygwin patch to fix /dev/clipboard usage and a similar 
> patch to cygutils for the utilities.
>
> I appreciate your help in uncovering and investigating bugs in 
> clipboard support.
> Thanks & Regards,
>
> ..mark
>

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

[Thomas Wolff]

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.
Thomas

>> So getclip and putclip will need fixing as well.
>>
>> I will submit a Cygwin patch to fix /dev/clipboard usage and a 
>> similar patch to cygutils for the utilities.
>>
>> I appreciate your help in uncovering and investigating bugs in 
>> clipboard support.
>> Thanks & Regards,
>>
>> ..mark
>>
>
>

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

[Lee]

On 9/26/21, 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?

speed?

Maybe I'm not understanding the question, but I put a question to this
list ~3 years ago about right-click/paste into a mintty window being
**really** slow and the answer was to use getclip:
$ time d2u < /dev/clipboard > hosts-3.txt

real    0m11.372s
user    0m3.749s
sys     0m6.984s

$ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt

real    0m4.405s
user    0m0.124s
sys     0m3.577s

$ time getclip -u > hosts.txt

real    0m0.734s
user    0m0.031s
sys     0m0.031s

Lee

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

[Brian Inglis]

On 2021-09-26 13:09, Lee via Cygwin wrote:
> On 9/26/21, Thomas Wolff wrote:
>> Am 26.09.2021 um 20:37 schrieb Thomas Wolff:
>>> Am 26.09.2021 um 11:50 schrieb Mark Geisert:
>>>> 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?

> speed?
> Maybe I'm not understanding the question, but I put a question to this
> list ~3 years ago about right-click/paste into a mintty window being
> **really** slow and the answer was to use getclip:
> $ time d2u < /dev/clipboard > hosts-3.txt
> real    0m11.372s
> user    0m3.749s
> sys     0m6.984s
> $ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt
> real    0m4.405s
> user    0m0.124s
> sys     0m3.577s
> $ time getclip -u > hosts.txt
> real    0m0.734s
> user    0m0.031s
> sys     0m0.031s

I'm not so worried about speed, except where that stops clipboard 
contents being updated quickly for consistency, but I ended up 
explicitly using /dev/clipboard under Cygwin for consistent 
interoperation with gvim and lxterminal under Linux VMs and gvim and 
mintty in Cygwin.

It would be good to test any changes across systems, or I could do so if 
the developer(s? - Mark?) don't run the environments to do so.

-- 
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.]

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

[Mark Geisert]

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

..mark

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

[Brian Inglis]

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?

-- 
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.]

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

[Takashi Yano]

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>

Re: 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.]

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

[Takashi Yano]

On Tue, 28 Sep 2021 00:46:15 -0600
Brian Inglis wrote:
> On 2021-09-28 00:19, Takashi Yano via Cygwin wrote:
> > On Mon, 27 Sep 2021 23:22:30 -0600
> > Brian Inglis wrote:
> >> 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 have checked the size of struct stat using:
#include <stdio.h>
#include <sys/stat.h>

int main()
{
	intptr_t offset0, offset_atime, offset_mtime, offset_ctime;
	struct stat t0;

	printf("sizeof stat=%ld\n", sizeof(struct stat));
	offset0 = (intptr_t) &t0;
	offset_atime = (intptr_t) &t0.st_atime;
	offset_mtime = (intptr_t) &t0.st_mtime;
	offset_ctime = (intptr_t) &t0.st_ctime;
	printf("offset st_atime=%ld\n", offset_atime - offset0);
	printf("offset st_mtime=%ld\n", offset_mtime - offset0);
	printf("offset st_ctime=%ld\n", offset_ctime - offset0);
	return 0;
}

In 32bit environment, the output is:
sizeof stat=96
offset st_atime=48
offset st_mtime=56
offset st_ctime=64

In 64bit environment, the output is:
sizeof stat=128
offset st_atime=48
offset st_mtime=64
offset st_ctime=80

It seems that the size of struct timespec is different.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

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

[Mark Geisert]

Hi Brian,

Brian Inglis wrote:
> On 2021-09-27 22:49, Mark Geisert wrote:
>> 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?

I'm not planning to include struct stat.  If that much info was needed for the 
original implementation back in 2012 it would have been added then.  I just 
observe that 'stat' and fstat() can show something useful with the feature.  I 
don't recall what other package or program had the requirement for the feature.
Cheers,

..mark