strcpy wars, jeez! A proposed resolution.

00704a-Liber nevin1 at ihlpf.ATT.COM
Sat Apr 9 04:21:42 AEST 1988


In article <17 at feedme.UUCP> doug at feedme.UUCP (Doug Salot) writes:
>[...]  While someone earlier
>pointed out that it is possible to design a language in which some semantics 
>can be described, C does not have this facility and seems to be
>philosphically antagonistic to such a facility.  I would indeed be
>surprised if a C compiler produced inline code for strcpy (unless you
>are talking about a macro, in which case the behavior of the code should
>be clear from reading the define), and the idea of compile-time
>warnings about function behavior seems equally out of place (maybe
>link-time would be appropriate).

I agree with you that C, the language, should not be designed in such a way
as to depend upon the semantics of a function being called.  However, when
it comes to optimization, it shouldn't matter whether or not the compiler
'knows' about the semantics of a function being called and optimizes based
on that fact (such as inlining instead of doing a function call).  The user
is supposed to be programming independent of the implementation of the
language (assuming it is implemented correctly), so whatever the compiler
wants to do in terms of correct optimization should not be restricted.

I feel that, for C, it is important to distinguish between defining the
language and defining its' implementation.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah



More information about the Comp.lang.c mailing list