Alexandre Julliard wrote:
Alex Villacís Lasso <[EMAIL PROTECTED]> writes:
Last week I sent the following patches that add DECIMAL support for
OLEAUT32:
1) Tests for all missing functionality:
http://www.winehq.org/pipermail/wine-patches/2005-September/020849.html
2) Call VarDecDiv and VarDecSub from variant.c:
http://www.winehq.org/pipermail/wine-patches/2005-September/020850.html
3) Correct scaling of high 32 bits of DECIMAL:
http://www.winehq.org/pipermail/wine-patches/2005-September/020851.html
4) Add full VarBstrFromDec support:
http://www.winehq.org/pipermail/wine-patches/2005-September/020852.html
5) Add full VarDecMul support:
http://www.winehq.org/pipermail/wine-patches/2005-September/020853.html
6) Add full VarDecDiv support:
http://www.winehq.org/pipermail/wine-patches/2005-September/020854.html
Of these, only patches 2 and 3 have been commited.
Could somebody explain (especially Mr. Alexandre Julliard) whether these
patches have been noticed? If so, what can be done to improve them?
The main problem I see is you are doing everything with bytes; it
would seem more natural and much more efficient to work with 32-bit
ints.
Also you are using malloc which should be avoided. If you really need
to allocate memory you can use HeapAlloc, but since all the numbers
are fixed size I don't think you should need allocations at all, stack
buffers should work fine.
I am a paranoid about endianness. I wanted absolute control over the
layout of the significant
bits, and working with bytes instead of 32-bit ints allowed me to port
the algorithms more easily,
in additon to being capable of using memmove for bit shifting. Why is
malloc() evil even if it is
only used internally and its memory is freed before returning the results?
Both this and the malloc issue can be fixed. However, I don't see why
this should prevent the
test patch from being submitted, unless there is a policy about not
allowing tests that do not yet
pass with current code.
Alex Villacís Lasso
