better code
Posted Jun 4, 2003 3:39 UTC (Wed) by
dododge (subscriber, #2870)
In reply to:
better code by tjc
Parent article:
strlcpy()
Pointer comparison is undefined if the pointers are not within the same object,
I've heard of this, but I have never read a good explanation. I just assumed that this restiction has something to do with pointer aliasing.
Well, it's undefined because the standard explicitly says so
:-). As to why the standard says so,
there is presumably some architecture out there that C works on
which cannot reliably support comparing arbitrary pointers; or
allowing this comparison might make it too difficult to implement
C on certain architectures. The most obvious reason for allowing
this would be to implement memmove, which the standard
already provides.
Portability discussions come up in comp.lang.c fairly
often, and someone occasionally chimes in with an example of a real
architecture they deal with where common-sense assumptions about
computer architecture don't hold true.
There's a lot of weird designs out there, and when you start
talking about embedded devices they may even have a larger installed
base than anything x86-derived. The worst case is
the "DeathStation 9000", a hypothetical
machine where even the most subtle undefined
behavior produces catastrophic results.
How is the performance of memmove()? Does it copy memory a double word at a time?
Depends on your C library, compiler, operating
system, chip architecture, etc. You'll have to examine
your libc source to find out how it's done for your system. And
you'll also have to check your compiler output to make sure
it actually calls the libc implementation. For example gcc 2.95.3
on sparc-sun-solaris produces inline assembly for small memcpy operations
rather than actually calling into libc.
Always use -Wall...
I'm rather fond of -ansi -pedantic -Wall -W myself
:-)
(
Log in to post comments)
