On Wednesday 10 December 2008 11:08:18 Cathey, Jim wrote: > If anyone wants my opinion,
We would have asked for it back in 2005 when this very issue was extensively discussed on this very list: http://www.busybox.net/lists/busybox/2005-July/015089.html > I greatly dislike using if(FOO) with > the expectation that the compiler will eliminate the code. Then you dislike building the Linux kernel, which relies heavily on this, and which is where I got it from in the first place. > I expect if() to be associated only with run-time decisions, > just as #if is with compile-time decisions. In fact, if cc > _were_ able to eliminate great gobs of code I'd even expect a > warning to that effect, as it is likely that that is NOT what > I as author intended. Dead code elimination was a common optimization technique back in the 1980's. Even Turbo C for DOS did it. It's about 30 years old. > While a well-behaved compiler can/should be able to do the > job, it cannot do it under all conditions where it is necessary. > (Consider a C source that is also compilable under VMS. This would not include BusyBox. > No way > the maze of #includes could even be handled without #if, much > less compiling its way past VMS-specific grubbage. I'm sorry you don't understand how modern compilers work. > So, given > that you have to use #if anyway for at least some code configuration > jobs, why not use it for everything? The classic paper "Ifdef considered harmful" is devoted entirely to answering that question. It was published in the USENIX proceedings 14 years ago, and you can read it here: http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful > After all, the C preprocessor > is one of the big reasons that C and all its derivatives are so > popular. It works, it is simple, and it's fairly unambiguous. Greg Kroah-Hartman's OLS paper from 2002 devoted a section to this. (The "no #ifdef in .c files" part.) The slides are here (slides 29-31 were on this): http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ And the paper is here (see page 6): http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_paper/codingstyle.ps There's audio of his talk somewhere, I might be able to dig up an MP3. > Is it really the intent, after all, that BB _only_ be usable > with gcc 4.x, presumably on Linux? How parochial! Please show me an implementation of perl other than Larry Wall's. So far you haven't mentioned a single target that GCC _doesn't_ produce output for. However, as I said, _TURBO_C_ did this. I built chunks of busybox with tinycc back before that project died. The PCC update the bsd guys are using is interesting. LLVM/clang is interesting. (By the way, some optimizations are REQUIRED these days. A compiler that can't do constant propogation violates the C99 standard. Did you notice that busybox is C99, not C89? Certainly not the K&R you seem to be familiar with?) But right now, the Linux kernel makes extensive use of gcc extensions, and only builds with gcc. (Ok, and Intel's closed source ICC which explicitly reverse engineered all the gcc extensions the kernel needed.) You seem unaware of that. You're sounding _remarkably_ uniformed. Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
