Memory and pointers

[narechk]

Consider:

// points to a valid, alloc:ed, aligned memory location
char* ptr_aligned = xxx;

// same but unaligned obviously
char* ptr_unaligned = xxx + 1;

// write short val to aligned_ptr
*(short*)ptr_aligned = val;

// write short val to unaligned_ptr
*(short*)ptr_unaligned = val;

printf("Ok.");
On most platforms this prints Ok. On sparc-solaris this spits out
SIGSEGV and coredumps.

Question: exactly what does the std say about this? UB? Then how does
one implement ie optimized memcpy without knowing alignment
requirements of target hardware?
Thanks,

- NK

[Pete Becker]

narechk wrote:

Question: exactly what does the std say about this? UB? Then how does
one implement ie optimized memcpy without knowing alignment
requirements of target hardware?

memcpy is part of the standard library. The library writer knows the
alignment requirements.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Andre Kostur]

"narechk" <na*****@gmail.com> wrote in news:1119359913.087806.40840
@g44g2000cwa.googlegroups.com:

Consider:

// points to a valid, alloc:ed, aligned memory location
char* ptr_aligned = xxx;

// same but unaligned obviously
char* ptr_unaligned = xxx + 1;
Nope, not obviously unaligned. May be running on a processor where 1
byte alignment is required.
// write short val to aligned_ptr
*(short*)ptr_aligned = val;

// write short val to unaligned_ptr
*(short*)ptr_unaligned = val;

printf("Ok.");
On most platforms this prints Ok. On sparc-solaris this spits out
SIGSEGV and coredumps.

Question: exactly what does the std say about this? UB? Then how does
one implement ie optimized memcpy without knowing alignment
requirements of target hardware?

Undefined behaviour. Happens that on the sparc, the CPU will trap an
unaligned memory access (which blows up your program). It's just not
required.

As for "optimizing memcpy".... I didn't think there's much you could do
to optimize memcpy. It copies a sequence of bytes from one memory
location to another. This implementation could range from effectively a
loop which copies byte-by-byte (which is probably the only "portable"
implementation), to some sort of implementation where you load some
registers with a start, end, and length value and make 1 CPU instruction
to perform the copy. But of course that would mean that you knew that
your target CPU supported that kind of instruction...

[narechk]

Andre Kostur wrote:

"narechk" <na*****@gmail.com> wrote in news:1119359913.087806.40840
@g44g2000cwa.googlegroups.com:

Consider:

// points to a valid, alloc:ed, aligned memory location
char* ptr_aligned = xxx;

// same but unaligned obviously
char* ptr_unaligned = xxx + 1;
Nope, not obviously unaligned. May be running on a processor where 1
byte alignment is required.

Right. Even/uneven/aligned/unaligned... I was kind of hoping my meaning
was getting through.

// write short val to aligned_ptr
*(short*)ptr_aligned = val;

// write short val to unaligned_ptr
*(short*)ptr_unaligned = val;

printf("Ok.");
On most platforms this prints Ok. On sparc-solaris this spits out
SIGSEGV and coredumps.

Question: exactly what does the std say about this? UB? Then how does
one implement ie optimized memcpy without knowing alignment
requirements of target hardware?
Undefined behaviour. Happens that on the sparc, the CPU will trap an
unaligned memory access (which blows up your program). It's just not
required.

Ok. Yes, there was no doubt as to why it coredumped, and the code was
modified to use byte memory accesses, but I was quite surprised to have
run into this. I've seen quite a few lines of code in the past which do
some really hairy pointer-memory-pointer stuff. In my case this is a
pool-like memory manager.

I take it this basically means that accessing memory in arbitrary
manner leads to UB (or is it UD?), at least as far as the standard is
concerned? Oh the joy of portable programming!


As for "optimizing memcpy".... I didn't think there's much you could do
to optimize memcpy. It copies a sequence of bytes from one memory
location to another. This implementation could range from effectively a
loop which copies byte-by-byte (which is probably the only "portable"
implementation), to some sort of implementation where you load some
registers with a start, end, and length value and make 1 CPU instruction
to perform the copy. But of course that would mean that you knew that
your target CPU supported that kind of instruction...

I'll rather eat my shorts than attempt to optimize memcpy and the likes
in ISO C++.
Many thanks,

- NK