strcpy wars, jeez! A proposed resolution.

[Cesar Quiroz]

Sender:

Followup-To:



This article was suggested by reading <4309 at ihlpf.ATT.COM>, by
(nevin1 at ihlpf.UUCP (00704a-Liber,N.J.)).  It is not a direct
response, though, but rather a side note prompted because one of his
arguments doesn't carry much force, but has been repeated many times
before.  Liber (and others before and, no doubt, after) says:

:... [I]t is quite possible to define an algorithm in such a way
:that it uses the *side effects* (aka, implementation-defined
:behavior) of such an operation.  If you are writing code like this
:then you are becoming very dependent on your particular
:version/implementation of C.
:
:Good luck in three years, when your implementation is outdated!

Before we get too excited about the purity of functional bahaviors,
let's remember that strcpy is used (in the overwheming majority of
cases) *to perform side-effects*.  It is perfectly legitimate to
want to clarify exactly *what* side-effects are guaranteed.  So,
when someone asks that the standard guarantee a certain order of
copying, it is a perfectly sensible thing to discuss whether that
side-effect is useful and reasonable to demand.

It is not as if you called a function from the math library and then
depended on the way your implementation leaves trash behind in your
fp registers...

If you are truly interested in defining an ADT String whose
implementation can be hidden totally, consider something along these
lines: (UNTESTED, CATCH THE IDEA, NOT THE CODE)

    typedef char *string;
    ...
    string
    fstrcpy (old)                   /* Functional STRing CoPY */
        string  old;

    {
        return strcpy((string)malloc((unsigned)strlen(old)+1), old);
    }

So you could use the side-effecting string package to write
a library that does not need to guarantee any side-effects, but can
be considerably more costly.

-- 
Cesar Augusto  Quiroz Gonzalez
Department of Computer Science     ...allegra!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz at cs.rochester.edu