On Sat, Jun 29, 2013 at 12:34 AM, Juan Lang wrote:
> Ah. Thanks for following the existing style then :-/ No, don't bother
> changing the existing code. I leave it up to you whether to follow my
> suggestion or ignore it, either is fine in this case.
Patch sent, thanks Juan Lang and Daniel Jelińs
On Fri, Jun 28, 2013 at 9:16 AM, Qian Hong wrote:
> Dear Juan,
>
> Thanks for reviewing!
>
> On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> > It's more in line with most C code to use !memcmp(...) instead of
> > memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to
> !
>
Dear Juan,
Thanks for reviewing!
On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> It's more in line with most C code to use !memcmp(...) instead of
> memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to !
> comparisons to check equality in memcmp, strcmp, and variants.
>
Hi Qian,
On Fri, Jun 28, 2013 at 3:44 AM, Qian Hong wrote:
> Hi Daniel, new patches sent with improving from your hints, would you
> mind have a look? Thanks in advance!
>
nice work! These look fine to me, but a stylistic nit:
+
ok(memcmp(pbData,cTestData[i].decstr,cTestData[1].enclen)==0,"dec
Hi Daniel, new patches sent with improving from your hints, would you
mind have a look? Thanks in advance!
Hi Daniel,
On Fri, Jun 28, 2013 at 4:47 PM, Daniel Jeliński wrote:
> I'm not convinced that a failed call to CryptDecrypt actually resets
> the key state. It's also possible that CryptDecrypt returns FALSE
> before even trying to decrypt if data length is invalid. To check it,
> you would need to
Hi Qian Hong,
I'm not convinced that a failed call to CryptDecrypt actually resets
the key state. It's also possible that CryptDecrypt returns FALSE
before even trying to decrypt if data length is invalid. To check it,
you would need to change the key state by (successfully) calling
CryptDecrypt wi
Hi Daniel,
On Fri, Jun 28, 2013 at 3:43 AM, Daniel Jeliński wrote:
> It is definitely valid to call CryptDecrypt multiple times with the same
> key. Calls with Final = FALSE change the internal state of the key, calls
> with Final = TRUE restore the initial state. Subsequent calls with Final =
>
It is definitely valid to call CryptDecrypt multiple times with the same
key. Calls with Final = FALSE change the internal state of the key, calls
with Final = TRUE restore the initial state. Subsequent calls with Final =
TRUE should return the same result.
Your testcase fails because CryptDecrypt
Hello,
I was investigating Bug 33898 [1] hardly and get a partial result, I
have a special test case demonstrate the behavior of Aliwangwang [2],
however, I failed to expand the special case to a common test case. My
attempting is shown in [3]. The hack in [3] works for Aliwangwang, but
the test c
10 matches
Mail list logo
