This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: /dev/clipboard corrupted


On Sat, Jul 21, 2012 at 01:12:35PM -0400, Gregg Levine wrote:
>On Sat, Jul 21, 2012 at 5:12 AM, Corinna Vinschen <> wrote:
>> On Jul 21 00:14, Thomas Wolff wrote:
>>> Am 19.07.2012 11:41, schrieb Corinna Vinschen:
>>> >On Jul  9 01:15, Thomas Wolff wrote:
>>> >>Am 04.07.2012 10:15, schrieb Corinna Vinschen:
>>> >>>On Jul  3 18:29, Thomas Wolff wrote:
>>> >>>>...
>>> >>>>* The current (CVS) code will not work if even the first character
>>> >>>>to be converted
>>> >>>>    needs more bytes than the buffer provides, e.g. if the
>>> >>>>application calls read() with length 1 only.
>>> >>>>    Some extra buffering would be needed to make it work then.
>>> >>>Yes, indeed.  I'll have a look.
>>> >>...
>>> >>>No, not yet.  This isn't exactly a regression from former behaviour.
>>> >>>Please provide a patch or remind me in a few weeks again.
>>> >>About the buffering I may send a patch when I find time.
>>> (Gave it a short try but no success yet.)
>>> >>>>* I had previously observed that with a read size of n only n-1
>>> >>>>bytes would be delivered
>>> >>>>    and thought this was on purpose because wcstombs appends a final
>>> >>>>nul to its result.
>>> >>>>    Now n bytes are returned (if available) and in fact the byte
>>> >>>>behind the read() buffer is
>>> >>>>    overwritten (see modified test program).
>>> >>>It's not Cygwin overwriting the byte, your testcase is...
>>> >>Both were, actually...
>>> >>>>...
>>> >>>>          n = read (fd, filebuf, filebuflen);
>>> >>>>          if (out_tty) {
>>> >>>>                  filebuf [n] = 0;
>>> >>>Hmm, what if n == filebuflen?
>>> >>I admit my test case was bogus in this respect *BLUSH*.
>>> >>However, yet the error is there, as a fixed test case reveals.
>>> >>Also your own testcase does print out "OVERWRITTEN".
>>> >I don't see this.  I use the same "Scoloplos" testcase and my
>>> >code does not print "OVERWRITTEN".
>>> Beware that for the test case, you need to do a Windows paste; cp
>>> testfile /dev/clipboard will not do because you would take the
>>> "CYGWIN_NATIVE" branch then. Copy from notepad or mouse-copy from
>>> mintty will do.
>>
>> No, it doesn't.  The clipboard was filled with Ctrl-A, Ctrl-C from
>> within notepad.
>>
>>
>> Corinna
>>
>> --
>> Corinna Vinschen                  Please, send mails regarding Cygwin to
>> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
>> Red Hat
>
>Hello!
>Group I just might be materializing into this discussion without all
>of the facts,

You should not be attempting to respond to this thread without
understanding the facts.  This isn't a chatty mailing list for relating
experiences.  We're dealing with real issues here.

>Meaning that I first created a directory for the stuff, changed into
>it, and then pasted the location for its code and then watched as it
>retrieved the code from that hosting entity. So far this has worked
>twice for me. And incidentally Corinna this was all done before your
>timely update was announced and is now being retrieved. (Thank you for
>that one.)

I'm sure Corinna appreciates the appreciation but this really has
nothing to do with cygwin-developers.  If you want to talk about your
Cygwin experience, use the main cygwin list.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]