[sldev] [VWR] OpenJPEG backtraces

[Dzonatas]

Anders Arnholm wrote:
> No good programmer in the world breaks ANSI C, with out really good
> reasoning behind it. The original expression made the hair in my neck
> rise, I have been tracking down and destroying that kind of code now in
> six months to make the transitions of code from RH8 (i386) to RHEL5
> (x86_64). It was about the typical code with assumptions of memory that
> don't work.
>   

Memory range is fine, as the malloc() before that statement padded it 
fine. It's just a compiler nuance that can't be portably used anymore. 
The "long" keyword would be a hack to fix it (as Nicholas suggested), 
but that doesn't actually correct the intention. The "unsigned" keyword 
(by it self) worked fine through 32 bit, 16 bit, and 8 bit. Now with 64 
bit, it will depend on the compiler options if "long" is needed or not. 
That would be the more of the event of C++ than the changes from "RH8 to 
RHEL5," as C++ creates the distinct type on "long."

Instead of worrying about compiler options/mode or the best expression, 
we can just result back to _mm_alloc() for now as defined in the xmm 
headers (and correctly for each compiler that supplies such headers). 
That is something we intended to do, but it would be nice to have 
something more portable than _mm_alloc(). The Mac has those headers, so 
it'll work for AltiVec, also.

The most portable expression (that gives no compiler warnings) becomes 
mandatory if we use other vector processors besides SSE and AltiVec. 
Also note, OpenJPEG was being compiled under C, but SL is set to compile 
it under C++.

This nuance is one of the reasons why people have screamed to implement 
into the standard the "align" (or "alignof") keyword on the "new" 
operator, such as:

mem = new align[16] char[1024];


-- 
Power to Change the Void