Re: Visual C++ aliasing issue

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

{} wrote:
Here is an example, where Visual Studio 2008 produces a code, that
does not work right when compiled with the default Release
configuration. The code works correctly in Debug.
Looks like SP1 has the same problem.

The code was working in VS2003.

The program copies an array of BGR elements into an array of BGRA
elements in place backwards (starting from the last element).

The variable tmp in the loop is introduced specially to prevent the
aliasing issue. The compiler optimizes the variable out however.

#include <malloc.h>

struct Pixel3 {unsigned char b, g, r;};
struct Pixel4 {unsigned char b, g, r, a;};
unsigned char* volatile pBufTmp = 0; //volatile to prevent unnecessary
optimizations here

You should use /**/ for comments that can wrap...

volatile int uiWidth = 3;

What's the meaning of 'uiWidth'? Number of elements?


int main(int argc, char* argv[])
{
pBufTmp = (unsigned char*)malloc(4 * uiWidth);

So, the question is, do you compile this as C or as C++? What is your default alignment requirement? What does 'sizeof(Pixel3)' yield?

And if you compile this as C++, why do you have to use 'malloc'? The recommended way is 'new[]'...

And your program could definitely use more comments. What's, for instance, is the meaning of '4' in the line above?

for (int k = 0; k < uiWidth; k++)
{
((Pixel3*)pBufTmp)[k].b = 0x30;
((Pixel3*)pBufTmp)[k].g = 0x20;
((Pixel3*)pBufTmp)[k].r = 0x10;
}
int iSrcBytesPP = 3;
int iDstBytesPP = 4;

It would seem you're writing C++, yet using a very ugly C style of managing memory. Ugly. I have no other word for it, sorry.

Here, for example, you're *assuming* that the number of bytes in the source struct is 3, whereas in fact it is 'sizeof(Pixel3)'. The same with the size of the destination. You *assume* it's 4, whereas it is actually 'sizeof(Pixel4)'.

unsigned char* pBufSrc = pBufTmp + (iSrcBytesPP * (uiWidth - 1));
unsigned char* pBufDst = pBufTmp + (iDstBytesPP * (uiWidth - 1));

You seem to use the same memory for source an destination... Are you sure you're not running over the boundary anywhere?

for (int k = 0, cc = uiWidth; k < cc; k++, pBufSrc -= iSrcBytesPP,
^^^^^^^^^^^^ ^^ Seems useless to declare 'cc'
just so it can be used as the upper limit. Why not 'k < uiWidth'?

pBufDst -= iDstBytesPP)
{
Pixel3 tmp = *(Pixel3*)pBufSrc; //copy to temp variable
*(Pixel3*)pBufDst = tmp;
((Pixel4*)pBufDst)->a = 255;
}

return 0;
}

Expected that the pBufTmp should contain elements 0x30, 0x20, 0x10,
0xFF, instead only the first element is the correct one, the rest is
set to 0x30, 0x20, 0x20, 0xFF.

You screwed up some offsets somewhere...

Ugh...

I think you meant to write

typedef unsigned char uc;
struct Pixel3 {
uc b, g, r;
Pixel3(uc b_ = 0, uc g_ = 0, uc r_ = 0)
: b(b_), g(g_), r(r_) {}
};

struct Pixel4 : Pixel3 {
uc a;
Pixel4(Pixel3 const& p3, uc a_)
: b(p3.b), g(p3.g), r(p3.r), a(a_) {}
};

int main(int argc, char* argv[])
{
const int uiWidth = 3;

Pixel3 pBufTmp = new Pixel3[uiWidth];
for (int k = 0; k < uiWidth; k++)
{
pBufTmp[k] = Pixel3(0x30, 0x20, 0x10);
}

Pixel4 pBufDest = new Pixel4[uiWidth];
for (int k = 0; k < uiWidth; k++)
{
pBufDest = Pixel4(pBufTmp[k], 255);
}

delete[] pBufDest;
delete[] pBufTmp;

return 0;
}

Or do you really need those arrays to be overlapping?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.

Relevant Pages

  • Billys Silly Things - Demo and Childrens Activity for DOS 3.3
    ... The compiler and tools will be updated shortly to include this demo ... unsigned char sillyname; ... int bottom = 0; ...
    (comp.sys.apple2.programmer)
  • Visual C++ aliasing issue
    ... The compiler optimizes the variable out however. ... struct Pixel4 {unsigned char b, g, r, a;}; ... int main ...
    (microsoft.public.vc.language)
  • Re: Why is this cast nessasary
    ... It does not work without the cast in this compiler. ... bit com_putchar (unsigned char c) ... be promoted to either int or unsigned int. ... So it could be an integer promotion issue. ...
    (comp.lang.c)
  • Re: CArchive: archiving booleans
    ... >compiler for the Cray did so, but I don't believe it was ever the ... >possibility of all the integer types being the same size. ... >is that EOF will fit in an int, but can be distinguished from any ... >possible value of char or unsigned char. ...
    (microsoft.public.vc.mfc)
  • Re: It Pays to Enrich Your C Skills
    ... Check if you can score a perfect 10 (without using a compiler). ... int main{ ... struct bitfield { ... out if it is a negative integer constant or a constant expression ...
    (comp.lang.c.moderated)