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] |
On Jul 9 01:15, Thomas Wolff wrote:(Gave it a short try but no success yet.)Am 04.07.2012 10:15, schrieb Corinna Vinschen:On Jul 3 18:29, Thomas Wolff wrote:...Yes, indeed. I'll have a look.... * 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.About the buffering I may send a patch when I find time.No, not yet. This isn't exactly a regression from former behaviour. Please provide a patch or remind me in a few weeks again.
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.Both were, actually...It's not Cygwin overwriting the byte, your testcase is...* 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).Hmm, what if n == filebuflen?... n = read (fd, filebuf, filebuflen); if (out_tty) { filebuf [n] = 0;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".
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |