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


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.


* I assume the current code will also fail in non-UTF-8 locales;
    if the wcs block being converted contains a non-convertible character,
    it would abort since wcstombs returns -1
    (assuming here that sys_wcstombs behaves alike in this respect)
It doesn't.  In fact, sys_cp_wcstombs was designed to never fail
to convert a string.  See the source code in strfunc.cc, line 447ff.
Tested meanwhile. My assumption was too speculative, sorry.

* 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".
This complies with the comment in strfuncs.cc:sys_cp_wcstombs:
   - The functions always create 0-terminated results, no matter what.
The fix is easy:
      if (pos < glen)
        {
          len --;       /* leave space for final NUL */
          ...

------
Thomas


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