From: Thomas Wolff <towo@towo.net>
To: cygwin-patches@cygwin.com
Subject: Re: /dev/clipboard pasting with small read() buffer
Date: Fri, 17 Aug 2012 08:44:00 -0000 [thread overview]
Message-ID: <502E0451.3020609@towo.net> (raw)
In-Reply-To: <20120816162245.GC14163@calimero.vinschen.de>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
On 16.08.2012 18:22, Corinna Vinschen wrote:
> On Aug 16 09:24, Eric Blake wrote:
>> On 08/16/2012 08:20 AM, Thomas Wolff wrote:
>>
>>>>> MB_CUR_MAX does not work because its value is 1 at this point
>>>> So what about MB_LEN_MAX then? There's no problem using a multiplier,
>>>> but a symbolic constant is always better than a numerical constant.
>>> I've now used _MB_LEN_MAX from newlib.h, rather than MB_LEN_MAX from
>>> limits.h (note the "_" distinction :) ),
>>> because the latter, by its preceding comment, reserves the option to be
>>> changed into a dynamic function in the future, which could then possibly
>>> have the same problems as MB_CUR_MAX.
>> POSIX requires MB_LEN_MAX to be a constant, only MB_CUR_MAX can be
>> dynamic. We cannot change MB_LEN_MAX to be dynamic in the future.
> ...also, Cygwin's include/limits.h doesn't mention to convert to
> a function.
Not sure how to interpret exactly what it mentions. Anyway, my updated
patch (using MB_LEN_MAX) proposes a change here as well.
------
Thomas
[-- Attachment #2: clipboard-small-buffer.patch.4 --]
[-- Type: text/plain, Size: 3548 bytes --]
diff -rup sav/fhandler_clipboard.cc ./fhandler_clipboard.cc
--- sav/fhandler_clipboard.cc 2012-07-08 02:36:47.000000000 +0200
+++ ./fhandler_clipboard.cc 2012-08-17 10:34:41.968750000 +0200
@@ -222,6 +222,7 @@ fhandler_dev_clipboard::read (void *ptr,
UINT formatlist[2];
int format;
LPVOID cb_data;
+ int rach;
if (!OpenClipboard (NULL))
{
@@ -243,12 +244,24 @@ fhandler_dev_clipboard::read (void *ptr,
cygcb_t *clipbuf = (cygcb_t *) cb_data;
if (pos < clipbuf->len)
- {
+ {
ret = ((len > (clipbuf->len - pos)) ? (clipbuf->len - pos) : len);
memcpy (ptr, clipbuf->data + pos , ret);
pos += ret;
}
}
+ else if ((rach = get_readahead ()) >= 0)
+ {
+ /* Deliver from read-ahead buffer. */
+ char * out_ptr = (char *) ptr;
+ * out_ptr++ = rach;
+ ret = 1;
+ while (ret < len && (rach = get_readahead ()) >= 0)
+ {
+ * out_ptr++ = rach;
+ ret++;
+ }
+ }
else
{
wchar_t *buf = (wchar_t *) cb_data;
@@ -256,25 +269,54 @@ fhandler_dev_clipboard::read (void *ptr,
size_t glen = GlobalSize (hglb) / sizeof (WCHAR) - 1;
if (pos < glen)
{
+ /* If caller's buffer is too small to hold at least one
+ max-size character, redirect algorithm to local
+ read-ahead buffer, finally fill class read-ahead buffer
+ with result and feed caller from there. */
+ char * conv_ptr = (char *) ptr;
+ size_t conv_len = len;
+#define cprabuf_len MB_LEN_MAX /* max MB_CUR_MAX of all encodings */
+ char cprabuf [cprabuf_len];
+ if (len < cprabuf_len)
+ {
+ conv_ptr = cprabuf;
+ conv_len = cprabuf_len;
+ }
+
/* Comparing apples and oranges here, but the below loop could become
extremly slow otherwise. We rather return a few bytes less than
possible instead of being even more slow than usual... */
- if (glen > pos + len)
- glen = pos + len;
+ if (glen > pos + conv_len)
+ glen = pos + conv_len;
/* This loop is necessary because the number of bytes returned by
sys_wcstombs does not indicate the number of wide chars used for
it, so we could potentially drop wide chars. */
while ((ret = sys_wcstombs (NULL, 0, buf + pos, glen - pos))
!= (size_t) -1
- && ret > len)
+ && (ret > conv_len
+ /* Skip separated high surrogate: */
+ || ((buf [pos + glen - 1] & 0xFC00) == 0xD800 && glen - pos > 1)))
--glen;
if (ret == (size_t) -1)
ret = 0;
else
{
- ret = sys_wcstombs ((char *) ptr, (size_t) -1,
+ ret = sys_wcstombs ((char *) conv_ptr, (size_t) -1,
buf + pos, glen - pos);
pos = glen;
+ /* If using read-ahead buffer, copy to class read-ahead buffer
+ and deliver first byte. */
+ if (conv_ptr == cprabuf)
+ {
+ puts_readahead (cprabuf, ret);
+ char * out_ptr = (char *) ptr;
+ ret = 0;
+ while (ret < len && (rach = get_readahead ()) >= 0)
+ {
+ * out_ptr++ = rach;
+ ret++;
+ }
+ }
}
}
}
diff -rup sav/include/limits.h ./include/limits.h
--- sav/include/limits.h 2011-07-21 22:21:49.000000000 +0200
+++ ./include/limits.h 2012-08-16 17:48:34.847141100 +0200
@@ -36,8 +36,7 @@ details. */
/* Maximum length of a multibyte character. */
#ifndef MB_LEN_MAX
-/* TODO: This is newlib's max value. We should probably rather define our
- own _mbtowc_r and _wctomb_r functions which are only codepage dependent. */
+/* Use value from newlib although 4 is sufficient */
#define MB_LEN_MAX 8
#endif
next prev parent reply other threads:[~2012-08-17 8:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 20:56 Thomas Wolff
2012-08-16 9:34 ` Corinna Vinschen
2012-08-16 12:12 ` Thomas Wolff
2012-08-16 12:31 ` Corinna Vinschen
2012-08-16 14:21 ` Thomas Wolff
2012-08-16 15:24 ` Eric Blake
2012-08-16 16:23 ` Corinna Vinschen
2012-08-17 8:44 ` Thomas Wolff [this message]
2012-08-17 9:23 ` Corinna Vinschen
2012-08-17 13:05 ` Thomas Wolff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502E0451.3020609@towo.net \
--to=towo@towo.net \
--cc=cygwin-patches@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).