BltBitMap() bug in OS4.1

I found a slightly obscure bug in OS4.1 update 2 on my Sam440.

The (latest OS4.1!) SDK says this about BltBitMap():
Quote:

And this does work as expected, when the minterm is 0xC0 (i.e. copy). But when the minterm is 0x80 (i.e. logical AND) then BltBitMap() behaves as if the minterm was actually 0xC0. I suspect it completely ignores the provided minterm, and always behaves as if the minterm was 0xC0.

Note that in my code both the source & destination bitmaps have a depth of 1 bitplane, and that the (destination) plane is allocated from the heap (rather than video memory). And note that my code behaves correctly if I replace the 0xffffffff plane pointer with a real plane that has all bits set to 1.

IMHO the easiest work-around would be for OS4 to temporarily allocate a real plane (of appropriate size & content) when it finds an 0xffffffff or 0x0 plane pointer & the minterm is not 0xC0. Of course it would be nice if OS4 also efficiently implemented a few more special cases (such as logical AND & OR minterms).