strange crash - cast short* to int*

[Gernot Frisch]

Hi,

the program below workes w/o problems on a GP2X and on the PC, but my
PocketPC (using GCC 3.3.3) crashes.
Very dissapointing, since I expect some speed boost from it.
Thnak you for your help.


int dx=..; // number of pixels width to draw
// one pixel is one unsigned short

// Get some pointer to the screen to draw a rect
unsigned short* pScreen = getColorBuffer(x,y);

int num_q = dx>>2; // number of 4 pixel pairs
int num_r = (dx & 0x00000003); // remaining pixels -> loop unrolling

// prepair a 2 pixel pair "long"
unsigned long colcol = col | ((unsigned long)col << 16);
// get a long pointer to that screen (draw 2 "shorts" at once)
unsigned long* pScLong = (unsigned long*)pScreen;
... loop for each line
for(register int rx=0; rx<num_q; ++rx)
{
#ifdef THIS_CRASHES
*pScLong++ = colcol;
*pScLong++ = colcol;
pScreen+=4;
#else
*pScreen++ = col;
*pScreen++ = col;
*pScreen++ = col;
*pScreen++ = col;
#endif
}
... remaining pixels and next lines...

 

[bonzo]

often on PocketPC CPUs dword read\write must be aligned on dword memory boundaries...

 

[acehreli]

There is no "getColorBuffer()" function in the standard C++ library. Try
asking for help on a newsgroup for your hardware platform.

How about dx, x, y, etc. Should the poster go elsewhere because they
are not in the standard as well? Do you have problems with people
using foo()? Is that standard?

You did not specify your platform-specific word sizes.

Why is that needed for the question? If the poster new that the
platform-specific word sizes had anything with it, he wouldn't be
surprised.

Assuming
sizeof(short)=2, and sizeof(long)=4, the above math does not add up. Again,
has nothing to do with C++, the language.

Do you know much about the C++ language? Are you claiming that sizeof
applied to types or their comparisons are not on-topic here? Your
releasing steam is off-topic here.

You can get a more definitive
answer on a more appropriate newsgroup.

This is an appropriate newsgroup. Why seek more?

Ali

 

[Kai-Uwe Bux]

How about dx, x, y, etc. Should the poster go elsewhere because they
are not in the standard as well? Do you have problems with people
using foo()? Is that standard?


Why is that needed for the question? If the poster new that the
platform-specific word sizes had anything with it, he wouldn't be
surprised.


Do you know much about the C++ language? Are you claiming that sizeof
applied to types or their comparisons are not on-topic here?

I did not read that in that part you quoted.

Your releasing steam is off-topic here.

Hm, the posting from Sam does not sound very aggressive, as opposed to
yours.

This is an appropriate newsgroup. Why seek more?

Because the topical answer to the OP is that the cast

unsigned long* pScLong = (unsigned long*)pScreen;

and the following usage of pScLong is undefined behavior. That answer is
clearly not helpfull but all that the standard has to say about his
program. Therefore, looking for answers elsewhere is a good idea.


Best

Kai-Uwe Bux

 

[James Kanze]

I did not read that in that part you quoted.

Hm, the posting from Sam does not sound very aggressive, as
opposed to yours.

His posting was presumptuous, and just noise, and of no help to
anyone.

Because the topical answer to the OP is that the cast

unsigned long* pScLong = (unsigned long*)pScreen;

and the following usage of pScLong is undefined behavior. That
answer is clearly not helpful

Isn't it? It's certainly a necessary starting point: the code
was illegal, and if it worked on some platforms, it was just by
accident.

One might also point out why it was decided that this should be
undefined behavior. General considerations about alignment,
etc., are also on topic here.

Presumably, of course, the problem is due to the fact that on
some platforms, long requires more strict alignment than short,
and that his original short* didn't meet those requirements. On
an Intel processor, this will slow things up considerably, but
the code will stil run; on most processors, alignement errors
will result in a hardware trap, which the system maps into a
core dump or something similar.

but all that the standard has to say about his program.
Therefore, looking for answers elsewhere is a good idea.

No. His problem is pure C++, and I don't know where else he
should look. The fact that he gets the original pointer from a
function which is not in the standard is completely irrelevant
(but the names do help us understand the context, and why he is
trying to do this).

 

[Kai-Uwe Bux]

His posting was presumptuous, and just noise, and of no help to
anyone.





Isn't it? It's certainly a necessary starting point: the code
was illegal, and if it worked on some platforms, it was just by
accident.

The "accident" is probably what is important.

One might also point out why it was decided that this should be
undefined behavior. General considerations about alignment,
etc., are also on topic here.

That was is Sam's posting.

Presumably, of course, the problem is due to the fact that on
some platforms, long requires more strict alignment than short,
and that his original short* didn't meet those requirements. On
an Intel processor, this will slow things up considerably, but
the code will stil run; on most processors, alignement errors
will result in a hardware trap, which the system maps into a
core dump or something similar.


No. His problem is pure C++,

I beg to differ. His problem, the way I understand it, is to write code that
works on the target platform. If that involves undefined behavior, so be
it. Why the particular code he proposes breaks is a matter of how the
platform defines the behavior left undefined by the standard. Also, what
possible fixes there are (to improve the speed) is platform specific.

and I don't know where else he should look.

Neither do I. But that does not imply that there is no better place.

The fact that he gets the original pointer from a
function which is not in the standard is completely irrelevant
(but the names do help us understand the context, and why he is
trying to do this).

True. But what the OP is trying to do with that pointer gives us a clue that
alignment is probably at the heart of the matter. What alignment
requirements he actually has, is platform specific.


Best

Kai-Uwe Bux