Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!osu-cis!att!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: strcpy wars, jeez! A proposed resolution. Message-ID: <4341@ihlpf.ATT.COM> Date: 8 Apr 88 18:21:42 GMT References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <6476@dhw68k.cts.com> <17@feedme.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 27 In article <17@feedme.UUCP> doug@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." / (_