I was bitten by a bug in strcpy which can cause an unwarranted core
dump.  The problem is that strcpy attempts to be efficient by reading
32 bits at a time and checking all 4 bytes for null in parallel. This
can result in reading up to 3 bytes past the terminating null which
can cause a core dump if in so doing it reads an unmapped page.

This can be fixed by aligning the source instead of the destination.
Only the corect number of bytes is ever written.

However, the problem also arises in strcmp. Here it is more difficult
to fix, because double word reads are done from both strings and it is
only possible to align one of them. In the case where S2 is longer
than S1 the (last) double word compare can cause up to 3 bytes to be
read from S1 past the terminating null. And the same possibility of a
core dump occurs. My suggestion here is to simply use an algorithm
like strncmp but with an effectively infinite count. Better to be
correct than fast!

A patch for strcpy is in pr port-pc532/7709 and a complete replacement
for strcmp is in port-pc532/7710.

This raises a couple of questions. If the double word at a time
approach is a win, why isn't it used for strncpy and strncmp. OK you
need a bit of extra code to keep count, but not that much. The second
question is are these "smart" algorithms worth it anyway? They look as
though they have quite a bit of extra overhead for short strings and I
would have though that short strings were more common than long ones.
Anyone really concerned with efficient handling of long strings, probably
shouldn't be using null terminated ones anyway!

Ian