2012/12/6 Alexandre Julliard :
> If you can't think of anything to test beyond the handful of cases you
> already have, then you shouldn't be implementing that function. There's
> no hope that your code will be able to cope with invalid input if you
> can't even imagine what invalid input could loo
Alex Henrie writes:
> 2012/12/5 Alexandre Julliard :
>> You have nowhere near enough tests to make such a claim. When I said to
>> write more tests, I didn't mean one or two more. You'd probably need at
>> least 100 tests to have decent coverage of all the interesting cases.
>
> It's not as much
2012/12/5 Alexandre Julliard :
> You have nowhere near enough tests to make such a claim. When I said to
> write more tests, I didn't mean one or two more. You'd probably need at
> least 100 tests to have decent coverage of all the interesting cases.
It's not as much of a technical problem as it i
Alex Henrie writes:
> Far from not addressing any of these issues, I feel that I have
> addressed all of them. More importantly, my implementation is correct;
> it matches Windows XP exactly.
You have nowhere near enough tests to make such a claim. When I said to
write more tests, I didn't mean
David Laight wrote:
> > I think encoding and decoding in UTF-7 arbitrary binary data was
> > considered a "feature" in Windows XP. As MSDN said, "Code written in
> > earlier versions of Windows that rely on this behavior to encode
> > random non-text binar
On Tue, Dec 04, 2012 at 08:30:55PM -0700, Alex Henrie wrote:
> 2012/12/4 Fr?d?ric Delanoy :
> > The above MSDN comment indicates pre-Vista versions are buggy, so it's
> > probably not a good idea to match that behaviour.
>
> I think encoding and decoding in UTF-7
Correction: Item 3 should have been "Put the code in kernel32."
-Alex
2012/12/4 Alexandre Julliard :
> Alex Henrie writes:
>
>> My implementation is modeled after Windows XP (Wine's default target
>> Windows version), which encodes and decodes arbitrary character
>> sequences without normalization. I saw that my submission has already
>> been marked "rejected"--was
2012/12/4 Frédéric Delanoy :
> The above MSDN comment indicates pre-Vista versions are buggy, so it's
> probably not a good idea to match that behaviour.
I think encoding and decoding in UTF-7 arbitrary binary data was
considered a "feature" in Windows XP. As MSDN said, &qu
Alex Henrie writes:
> My implementation is modeled after Windows XP (Wine's default target
> Windows version), which encodes and decodes arbitrary character
> sequences without normalization. I saw that my submission has already
> been marked "rejected"--was this why?
It was rejected because you
On Tue, Dec 4, 2012 at 5:30 AM, Alex Henrie wrote:
> 2012/12/2 Dmitry Timoshkov :
>> Also you probably need to add support for composition/
>> surrogates like other implementations do.
>
> MSDN states:
>
> "Starting with Windows Vista, this function fully conforms with the
> Unicode 4.1 specificat
2012/12/2 Dmitry Timoshkov :
> Why don't you put it in libs/wine where other unicode conversion routines
> are implemented?
Before I started this project I asked where to put the functions:
http://www.winehq.org/pipermail/wine-devel/2012-January/093705.html
I received no reply, so I put them in l
Alex Henrie wrote:
> I came back to the problem of UTF-7 support and made some improvements
> to my previous submission. The tests are now more stringent, especially
> in regard to null terminator checking, and they test the srclen
> parameter more thoroughly now as well.
>
&
Alex Henrie writes:
> 2012/9/3 Alexandre Julliard :
>> You don't have a single test with an explicit source length, so
>> obviously you are not going to find problems in that area. Like I said,
>> you need a lot more tests.
>
> example_2 already tests an explicit source length. In all the other
>
2012/9/3 Alexandre Julliard :
> You don't have a single test with an explicit source length, so
> obviously you are not going to find problems in that area. Like I said,
> you need a lot more tests.
example_2 already tests an explicit source length. In all the other
examples srclen = strlen(src) +
Alex Henrie writes:
> I was asked to split this patch up, so I did. The complaint about the
> last version was "You are still overflowing the source." I have not
> been able to find any test case that my implementation handled
> incorrectly, however, I did find that (*src == 0 && srclen < 0) will
Alex Henrie writes:
> Try 5 adds two tests for the case where srclen < -1 and passes them both.
You are still overflowing the source.
You need to spend more time on this. You also need to split the patch,
and write some sort of table-driven tests so you can test a lot more
cases, the ones you h
Alex Henrie writes:
> +do
> +{
> +if (src[source_index] == 0 && srclen == -1)
> +{
> +if (dry_run) dest_index++; else if (write_to_w_string(dst,
> dstlen, &dest_index, 0)) return -1;
> +/* when srclen=-1, terminate at the first null character found
Correction: I meant to write that try 4 exits the loop slightly faster when
ending a base64 sequence, it has nothing to do with escaped plus signs
which are handled a few lines earlier.
-Alex
Alex Henrie writes:
> Fixes bug 27388.
>
> This patch has been in the queue since May 21. I'm open to feedback.
It should all be in kernel32, not in libwine. Also you must do it
without memory allocations. You'd also want more tests for the overflow
cases, in particular for partial sequences.
-
UTF-8 is trivial, using iconv would be more work than doing it by
hand. UTF-7 is slightly more complicated but not that hard.
--
Alexandre Julliard
julli...@winehq.org
2012/5/8 Alexandre Julliard :
> That code is hopelessly ugly, and broken in various ways. You are
> probably better off starting from scratch.
Okay. Could we use the POSIX iconv functions? Why doesn't Wine use
iconv for UTF-8 already?
-Alex
Alex Henrie writes:
> Hi all,
>
> Could I get some feedback on
> http://source.winehq.org/patches/data/85898 ? It was marked "Rejected"
> a week ago without explanation.
>
> Most of the code was authored by Katayama Hirofumi, whose patches have
> been accepted into Wine before. He gave permission
t should all be int? Do LPCSTR and LPCWSTR need to be
> changed to something else as well?
I'm GUESSING that it all needs to be changed to match the surrounding
definitions.
>> 4) No new tests to confirm the behaviour is correct (or mention of
>> current tests succeeding)
>
d all be int? Do LPCSTR and LPCWSTR need to be
changed to something else as well?
> 4) No new tests to confirm the behaviour is correct (or mention of
> current tests succeeding)
dlls/kernel32/tests/locale.c already has just as many UTF-7 tests as
it has UTF-8 tests. What tests do we need
On 8 May 2012 11:21, Alex Henrie wrote:
> Hi all,
>
> Could I get some feedback on
> http://source.winehq.org/patches/data/85898 ? It was marked "Rejected"
> a week ago without explanation.
Without being a regular contributor, here are a few tips from a cursory glance:
1) Whitespace change on at
Hi all,
Could I get some feedback on
http://source.winehq.org/patches/data/85898 ? It was marked "Rejected"
a week ago without explanation.
Most of the code was authored by Katayama Hirofumi, whose patches have
been accepted into Wine before. He gave permission to use his code
under the LGPL at h
Hello,
I have been thinking about implementing UTF-7 support in
MultiByteToWideChar and WideCharToMultiByte. The guts of the code that
needs to be added have already been posted to bug 27388. What more
needs to be done? Should a libs/wine/utf7.c file be created for the
new functions, similar to
28 matches
Mail list logo
