On Dec 11, 2007 7:48 PM, Nuno Lucas <[EMAIL PROTECTED]> wrote:
>
>
> http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes
>
> Don't know how I forgot to include that option, sorry. Probably too
> focused on portable code.
>
>
> Regards,
> ~Nuno Lucas
>
Hi,
I presumed it's something to do with __attribute__ however I am still
unable to isolate the one I need ;)
The "aligned" would sound like what I want, but upon reading it
further, I'm confused. It's not something to be used with malloc(),
right? Our code does something like this (please allow for any
mistakes, this isn't "real" code)
uint8_t getu8(char **p) {
uint8_t a = **p;
*p ++;
return a;
}
uint16_t getu16(char **p) {
uint16_t a = **p + (*(*p+1) << 8); // please ignore endianess
*p +=2;
return a;
}
void function() {
char *buffer, *p;
uint32_t *x;
buffer = malloc(500); // theoretically aligned to 32-bits?
buffer[0] = 0;
buffer[1] = 5;
buffer[2] = 8;
buffer[3] = 1;
buffer[4] = 2;
buffer[5] = 95;
....
buffer[499] = 13;
p = buffer; // p is now aligned to 4 bytes, right?
getu8(&p); // now it's p%4 == 1, right?
getu16(&p); // now it's p%4 == 3, right?
// so we're now pointing with p at the memory that we reached
after getting some data from the buffer
// the memory p points to is not aligned to 4
// we do, however, need to use the numbers that follow as 32bit integers
x = (uint32_t*)p;
x[0] = x[1] + x[2];
// it would be silly if we could not circumvent this crash with a
compiler feature
// which, if really necessary, would add some instructions before
accessing the element
// similar to those i mentioned in a mail from 19:38 CET
// and in such case use an alternative way to construct a valid
integer in the register
// (personally i'd be happy to live with additional instructions in
case they're optional)
}
If anyone would like to test the "actual" code we're discussing, SVN is here:
http://opentibia.svn.sf.net/svnroot/opentibia/yatc/trunk/
The encryption code that causes crashes is in folder
net/encryption.cpp and I've added ugly #ifdef to make it memcpy() if
running on WINCE. The protocol we use (a reverse engineered protocol)
is designed the way that we receive a message size (2 bytes) and then
the XTEA encrypted message. Once decrypted, we have a message size (2
bytes) then packet id (1 byte) then custom data, then again packet id,
then custom data, etc etc. Custom data varies in size and number of
components.
--
Ivan Vučica
-- Croatia --
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
