> Just something funny for in between... > I am now looking over all calls to memcpy() because i got a crash > on OpenBSD on a perfect subject to memcpy(), effectively a string > move forward (i.e., leftwise). I never would have even thought on > anything else but
memcpy is undefined for overlapping copies; the stronger alternative interpretation of undefined is *TOTALLY UNSAFE* It isn't just undefined -- it trashes memory. For such circumstances, you must use memmove instead. To save everyone grief our memcpy discovers this circumstance and crashes the program. This has led to the discovery of quite a few bugs. > // the difference to Copy is that this fn handles overlapping regions, > // i.e., starts at the end if source (_from) LT destination (_to). > // so what we do is easy and thus we just jump off to copy unless we > // can't. this works because the functions use equal stacks and so. > > so that i became a hundred percent used to that. Yes, now i read > that the standard says "If copying takes place between objects > that overlap, the behavior is undefined", but they don't overlap, > do they -- you have to load before you store. load before you store will work for 1 storage unit only (generally a byte), after that you are trashing memory unless it works in reverse like memmove does. memcpy does not move backwards. Only bcopy (not widely standardized) contains the logic to determine safe direction of copy.
