Implementation-DEPENDENT code (was:strcpy)

[Chris Torek]

In article <4331 at ihlpf.ATT.COM> nevin1 at ihlpf.ATT.COM (00704a-Liber) writes:
>The reason that I do not like the proposed change
[to the proposed dpANS to make strcpy(s,s+n) defined]
>is because it ENCOURAGES implementation-dependent code, which, to
>put it simply, is a *bad* programming paradigm.

Once again, IF THE CHANGE WERE MADE, IT WOULD NOT BE IMPLEMENTATION
DEPENDENT.

You believe that strcpy(s,s+n) is somehow inherently `bad'.  We
disagree.  But you cannot claim that, if this change were made,
such usage would be implementation defined; you can only claim that
in your opinion it would still be bad.  You can (and do) claim that
if the change is NOT made, such calls will be implementation
dependent.  You cannot make any claim beyond opinion about such
calls NOW without defining C-as-it-is.

>One of the arguments for the change is "I have some code now which relies
>on the fact that strcpy() is left-to-right."  Since this code does not
>conform to C as it is defined now, [material deleted]

Where is C defined now?  K&R?  No: their strcpy does not even have a
return value.  The implementation?  No: there are many implementations,
and some of them disagree.  Is it defined by the applications that use
it?  No, for some of them are buggy.  Perhaps the only definition is
that `C is what Dennis Ritchie says it is.'  But I doubt you will
accept that one either.  Well, we do not accept yours any more than you
accept ours.  And therein lies the war.

I agree to let you believe that strcpy(s,s+n) `inherently bad'.  Will
you agree to let me believe that it is not so, that it is only bad if
we arbitrarily *define* it as bad?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris