Date: Wed, 30 Jan 2002 18:19:46 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@village.org> Cc: deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <3C58A9C2.6890CB19@mindspring.com> References: <63609.1012386890@axl.seasidesoftware.co.za> <3C5895A5.D65A3ADB@mindspring.com> <20020130.183139.84750367.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote: > I am an embedded systems vendor. A new version of ssh or groff is > much more of a pita than this change because that has files > added/deleted from the tree. The worst that can happen with this > change is minor conflicts... I don't think it will be an issue. This is the "it hurts more if I am stabbed in the liver than if I stub my toe, so I'm not going to avoid stubbing my toe" argument. 8-). > Cross compilers exist. unprotoize exists for use with K&R compilers. Yesm, I agree. These are toes stubbed on the barrier to entry: it doesn't prevent you from entering, but it is pain that you would not have otherwise had to endure. > However, K&R compilers have several features of modern C missing. > 1) no long long support Questionable value on 32 bit architectures. > 2) no void support > 3) no const support These are for the optimization convenience of the compiler; older compilers didn't have them, and cdefs.h "zaps" them out, along with "volatile". > 4) no long double support See #1. > 5) "string " "concat" doesn't work I don't know how concerned I am about this; how often is this used in FreeBSD source code? > 6) All struct member names are from one global name space Yes. This is a protability issue, like knowing that you can't use "register" within scopes inferior to function level scoping, and still compile on certain compilers and have correct code generated, or knowing that a negative pointer reference on an utho variable pointer to a statically allocated area may not generate the correct code, e.g.: char *p = "Hello World" + 6; printf( "p = '%s'\n", p); printf( "p-6 = '%s'\n", p - 6); This is why stat structure members have "st_" prefixes on their members. It's interesting to note that POSIX has writ this convention into standard for well known interfaces. > 7) Many small, but potentially significant minor changes > in semantics make it difficult to ensure that the code > will work in a K&R world. Actually, going the other way is harder. A K&R compiler will generate working code for ANSI C code, stripped of the qualifiers used to make the compiler writer's life easier, but an ANSI C compiler will generate incorrect code in a number of cases for historically correct code (e.g. register optimization of a global loop control variable that is modified from a signal handler, causing the code to loop forever, unless the volatile keyword is used on the variable -- also a convenience for the compiler writer). In general, I would say that ANSI C adds semantics for the code to give hints to the compiler about invalid assumptions that the compiler would otherwise be permitted to make. This permits ANSI C compilers to generate better code without a lot of additional effort on the part of the compiler writers being required to employ these optimizations. So, in general, the main worry is K&R C code that breaks when compiled with ANSI C compilers, rather than the other way around (assuming cdefs.h strips the unsupported keywords). > 8) Library support is radically different in K&R. free(NULL) > was fatal, not explicitly allowed. Different ways of > doing tty manip, etc are all barriers to entry short of > a full port. Yes, there are API differences over time. Linking the compiler technology to the time is not completely valid in this case, however. [ As an historical note, I'll point out that "free(NULL)" was an explicit invocation of the coeslescing of free space according to "The C Programming Language", and that tty manipulation can be abstracted down to 6 system interfaces, and made relatively very portable; I wrote code that ran on approximately 140 vendor implementations of UNIX, with only 3 variant files. ] > 9) no support for prototypes This is really a language problem. Prototypes were added to C for 5 primary reasons: 1) Avoid the sign extension to "int" on the stack 2) Allow standardized passing of larger-than-int values 3) So that C programs could be compiled with C++ compilers, which were considered to be the future technology path for C evolution 4) To do usage checking which could just as easily been done at link-time, if there had been symbol attribution in the object file (i.e. to get the benefit of the checking without changing the object file format). 5) To avoid the "glue code" generation that would have been required to achieve these, if the glue code generation at link time had been used in order to let the link go through (i.e. as a latency fix for bsd programmers, that didn't result in executable size bloat). > ... > > FreeBSD uses these all over the place, making a port of most of the > FreeBSD source to a K&R compiler hard. The FreeBSD doesn't support > K&R compilers, so it shouldn't pretend to do so. I guess I have to refer back to my original posting again, then, to note that the FreeBSD policy is to introduce the incompatabilities in new code. The issue, once again, is not necessarily about supporting K&R compilers with new code. It's about gratuitous changes. If you could get agreement from the NetBSD and OpenBSD core teams that conversion was NetBSD and OpenBSD policy, and made it FreeBSD policy, then most of the arguments against it as a gratuitous change devolve into historical reference for substantive changes being more difficult, and to the (usually commercial) non-project use of the code. I think we could eat that, even if some of us didn't like the taste. > : I wish you would at least gain the consensus of the OpenBSD > : and NetBSD projects, as well. > > NetBSD already is agressively moving to pure ANSI C. As near as I can > tell, OpenBSD hasn't made up its mind yet. Maybe this will help them. What does the NetBSD core team say? I'm not talking about commits, which like Rod Grimes' whitespace patch, might be backed out by the-powers-that-be, I'm asking about what the-powers-that-be have to say about it. I think a cross-BSD agreement to change (or not) would be a good thing. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C58A9C2.6890CB19>