Re: /dev/clipboard pasting with small read() buffer

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug 17 10:44, Thomas Wolff wrote:
> 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.

This is from the time I was working on the extended locale support
in Cygwin 1.7.  I have not the faintest idea anymore what I was trying
to say with this comment.

>  Anyway, my
> updated patch (using MB_LEN_MAX) proposes a change here as well.

Thanks.  I dropped the hint that 4 is enough.  I'm not so sure about
that.  Linux, for instance, defines MB_LEN_MAX as 16.

Other than that, patch applied.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat