Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit

2021-10-23 Thread Takashi Yano
Hi Corinna,

On Fri, 22 Oct 2021 17:11:13 +0200
Corinna Vinschen wrote:
> Just to close this up prior to the 3.3.0 release...
> 
> Given we never actually strived for 32<->64 bit interoperability, it's
> hard to argue why this should be different for the clipboard stuff.
> 
> Running 32 and 64 bit Cygwin versions in parallel doesn't actually make
> much sense for most people anyway, unless they explicitely develop for
> 32 and 64 bit systems under Cygwin.  From a productivity point of view
> there's no good reason to run more than one arch.
> 
> So I agree with Ken here.  It's probably not worth the trouble.

Current code below in fhandler_clipboard.cc causes access violation
if clipboard is accessed between 32 and 64 bit cygwin.

  cygcb_t *clipbuf = (cygcb_t *) cb_data;

  if (pos < (off_t) clipbuf->len)
{
  ret = ((len > (clipbuf->len - pos)) ? (clipbuf->len - pos) : len);
  memcpy (ptr, clipbuf->data + pos , ret);
  pos += ret;
}

Don't you think this should be fixed?

-- 
Takashi Yano 


Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit

2021-10-23 Thread Mark Geisert

Ken Brown wrote:

On 10/23/2021 1:35 AM, Mark Geisert wrote:

Corinna Vinschen wrote:

Just to close this up prior to the 3.3.0 release...

Given we never actually strived for 32<->64 bit interoperability, it's
hard to argue why this should be different for the clipboard stuff.

Running 32 and 64 bit Cygwin versions in parallel doesn't actually make
much sense for most people anyway, unless they explicitely develop for
32 and 64 bit systems under Cygwin.  From a productivity point of view
there's no good reason to run more than one arch.

So I agree with Ken here.  It's probably not worth the trouble.


Sorry, I've been sidetracked for a bit.  I can agree with Ken too.  The only 
circumstance I could think of where multiple internal format support might be 
useful (to non-developers) was some user hanging on to an older Cygwin because 
it was needed to support something else (s/w or h/w) old and non-upgradeable. 
Doesn't seem very likely at this point.


I'll try to get the v2 patch out over this weekend.  Same end-result for same 
environments as the v1 patch, but incorporating all the comments I received.


I think Corinna was saying that the whole idea of making the 32-bit and 64-bit 
clipboards interoperable is not worth the trouble.


Oh, I didn't read it that way.  But that works for me too.  Color it dropped 
:-).
Thanks,

..mark


Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit

2021-10-23 Thread Ken Brown

On 10/23/2021 1:35 AM, Mark Geisert wrote:

Corinna Vinschen wrote:

Just to close this up prior to the 3.3.0 release...

Given we never actually strived for 32<->64 bit interoperability, it's
hard to argue why this should be different for the clipboard stuff.

Running 32 and 64 bit Cygwin versions in parallel doesn't actually make
much sense for most people anyway, unless they explicitely develop for
32 and 64 bit systems under Cygwin.  From a productivity point of view
there's no good reason to run more than one arch.

So I agree with Ken here.  It's probably not worth the trouble.


Sorry, I've been sidetracked for a bit.  I can agree with Ken too.  The only 
circumstance I could think of where multiple internal format support might be 
useful (to non-developers) was some user hanging on to an older Cygwin because 
it was needed to support something else (s/w or h/w) old and non-upgradeable. 
Doesn't seem very likely at this point.


I'll try to get the v2 patch out over this weekend.  Same end-result for same 
environments as the v1 patch, but incorporating all the comments I received.


I think Corinna was saying that the whole idea of making the 32-bit and 64-bit 
clipboards interoperable is not worth the trouble.


To that end, does Jon's suggestion of /usr/include/sys/cygwin.h seem like the 
best location to define struct cygcb_t for use by both Cygwin and cygutils package?

Thanks much,

..mark