Alexandre Julliard wrote:
Alex Villacís Lasso a_villacis@palosanto.com writes:
Last week I sent the following patches that add DECIMAL support for OLEAUT32:
- 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