On Sun, 2006-07-16 at 14:52:41 +0300, ext Tomi Ollila wrote:
Also, maybe better (or worse!) is (char *)(((int)address + 3) ~3),
assumed that sizeof (char *) == sizeof (int).
This latter version seems to compile...
And runs... on this architecture, but not on others. ;)
If you have to use
On Sat, 2006-07-15 at 23:19 +0300, Tomi Ollila wrote:
Philip Van Hoof [EMAIL PROTECTED] writes:
If somebody feels brave, feel free to assist me in getting it 4 byte
aligned ;-). I don't have a lot experience here.
(((char *)address + 3) ~3)
I simply use this on each char* pointer?
Philip Van Hoof [EMAIL PROTECTED] writes:
On Sat, 2006-07-15 at 23:19 +0300, Tomi Ollila wrote:
Philip Van Hoof [EMAIL PROTECTED] writes:
If somebody feels brave, feel free to assist me in getting it 4 byte
aligned ;-). I don't have a lot experience here.
(((char *)address + 3) ~3)
On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote:
When I run tinymail behind a camel with the mmap() patch, on the device,
it will get killed by the kernel (it's not a Segfault, it's a kill by
the kernel).
When I run tinymail (behind a camel with the mmap..) on my desktop or in
On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote:
When I run tinymail behind a camel with the mmap() patch, on the device,
it will get killed by the kernel (it's not a Segfault, it's a kill by
the kernel).
When I run tinymail (behind a camel with the mmap..) on my desktop or in
On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote:
When I run tinymail behind a camel with the mmap() patch, on the device,
it will get killed by the kernel (it's not a Segfault, it's a kill by
the kernel).
When I run tinymail (behind a camel with the mmap..) on my desktop or in
On Fri, 2006-07-14 at 11:15 +0100, Ross Burton wrote:
On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote:
When I run tinymail behind a camel with the mmap() patch, on the device,
it will get killed by the kernel (it's not a Segfault, it's a kill by
the kernel).
When I run
Hi,
I know I had to use some guint32's, maybe those are differently written
to the file on ARM?
On ARM memory accesses have to be aligned (e.g. long = 4 bytes,
so long accesses have to be aligned to 4 bytes).
AFAIK ANSI-C standard guarantees that structure members are always in
the same order
