On Wednesday 10 December 2008 20:05:23 Cathey, Jim wrote: > >We would have asked for it [my opinion] back in 2005 > >when this very issue was extensively discussed... > > My, that's rather rude. Did I kick your puppy or > something?
A very useful heuristic is that any post starting with an "IMHO" variant is going to be an ego-fest, just like "with all due respect" tends to precede insults. The need for disclaimers and "methinks the lady doth protest too much" aren't 100% correlated, but it still perks up the antennae. I've fallen into the habit of treating things that start with disclaimers as if they _needed_ them. If I overreacted, I apologize. > I was not _on_ this very list back in 2005, > I don't see why you think I would have been, nor how > you could think that I _should_ have been. Nor do I expect you to check the archives before jumping in with your opinion on an issue that was extensively discussed back when it was implemented. Nor do I expect you to have read the FAQ: http://busybox.net/FAQ.html#arch http://busybox.net/FAQ.html#standards http://busybox.net/FAQ.html#portability > >>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. > > Yes. And I still find it tremendously parochial. I stand by > my statement: I much prefer a clear expression of code that > I expect to be eliminated, versus code that I do not. BusyBox is a Linux project. Its origins trace back to a Linux installer, the modern project was launched by a Linux developer, and historically it's always taken its cues on "what does good open source development look like" from the Linux development community. My argument boils down to "Linux is a good role model for how to do this", and yours to "I don't like how Linux does this". In my favor is the fact that this not hampered Linux's success in any way of which I am aware. For several years now BusyBox has been interested in supporting non-Linux build environments where convenient (hence platform.h and friends), but arguing that "the way Linux does this is wrong, use my system's way instead" misses the point of the project. > >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. > > Yes. That's not the point I was making. I didn't notice you making a point, I thought you were expressing an opinion. > >This [VMS] would not include BusyBox. > > Should I have used a different example? I thought it was > pretty clear to invoke a clearly non-Unix platform that had > at least some fame in the industry. *blink* *blink* Busybox exists to implement small simple versions of the Single Unix Specification version 3 command line utilities, primarily for Linux. We explain this in our FAQ. We link to the spec on the web. In that context, you bring up a non-Unix platform, one that Busybox has never has run on that I'm aware of, while presumably discussing busybox, on the busybox mailing list. > Although, in this case, > perhaps merely citing some non-Linux-2.6, non-gcc-4.X platform > would have been sufficient. ("We've got both kinds, Country > _and_ Western!") > > >I'm sorry you don't understand how modern compilers work. > > Perhaps I don't. But if I'm trying to support both Linux and > OSE platforms (and I do this at work), it's rather difficult > to deal with the decision to include <efs.h> or <unistd.h> > without using #if. If you'd read any of the references or any of the discussion history you'd note that headers get eliminated _from_.c_files_. They get moved _into_ header files, such as "platform.h", which is a nest of #ifdefs by its very nature. (They should still be kept down to a dull roar in there, but that's where you can't totally get rid of them from.) > Hiding it in another layer doesn't count, > not if it's still there. Exporting the problem into sed-world > doesn't count, either. Wasn't that exactly what you suggested doing in a recent message to Peter Korsgaard? > I did turn down a job at Diab some time ago. Their compiler's > author said that I was the only person not already working there > that understood how it worked. (Perhaps they liked that I, a > mere customer, was able to re-target it to the TMS34010. That > code is still in use today, in banks.) But I didn't want to move > to CA. (The Diab compiler kicked the snot out of the AT&T > compiler of the day, and gcc. It's still well thought of, and > is a current offering of Wind River for the embedded market.) > > But it's old. Doesn't count. I taught Java courses at the local community college, wrote half the install software for OS/2 4.0 (including my own regex implementation, and my first experience cross compiling was working on OS/2 for the PowerPC with that horrible watcom compiler), before that wrote a multi-line Fidonet BBS for DOS with Desqview and FOSSIL drivers that had no synchronization primitives other than file locking yet still managed 30 messages/second on a 33 mhz 386, and before that wrote rather a lot of programs for my commodore 64 in compiled basic with the occasional bout of 6502 assembly (really 6510, but who's counting?). I learned from all of this, but I'm not holding any of it up as evidence of modern day best practices for open source C99 programs for Linux. > >(The "no #ifdef in .c files" part.) > > They can certainly be abused. Part of our job is to keep > our hands out of the rotating knives. But that doesn't mean > I think we should go back to using sheep to mow the lawn, either. The point of if(ENABLE) is to reduce the need for #if ENABLE as much as possible. We added USE() macros to further reduce the need for #ifdefs, but that changes syntax based on #ifdefs and if(ENABLE) doesn't. A significant advantage of if(ENABLE) over #ifdef and USE() is preventing configuration option changes from causing build breaks. Before we went on the first major #ifdefectomy, we regularly had configurations that didn't even _compile_, and we never knew about it until we tried that particular combination of config options (and testing them all is essentially impossible because the number of combinations increases exponentially with the number of config symbols). That is a pragmatic, measurable reason why one approach is superior to another. It is not the only one. > >>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. > > Huh? You're complaining about using gcc as a standard compiler. The entire perl programming language has only ever had one implementation, and they spent years trying to rebase that on parrot and failed. So every perl program anywhere is dependent on a single codebase to run itself, but that codebase is open source and portable so they cope. I'm not saying perl is a good example of anything, I actually despise that language. What I'm saying is you have a strange definition of "parochial" when your definition excludes one of the ten most popular programming languages in the world. (It's fallen from sixth to eighth in the past year: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html and good riddance, but still top ten. And that's not even counting Visual Basic, or the fact C# had to be reverse engineered to get a second implementation, since we're presumably restricting our discussion to open source programming by the context in which it's taking place and thus Microsoft doesn't enter into it.) > >So far you haven't mentioned a single target that GCC _doesn't_ > >produce output for. > > The list of targets that gcc no longer will produce output for > is longer than the list for which it will. One doesn't have to > look far. I believe that's called "hand waving". You _still_ haven't mentioned a single specific target of interest which might provide a concrete example of a downside of the current approach. Back in 1992 I took an assembly language course for a Hewlett Packard minicomputer that did all its math in Binary Coded Decimal. Only course I ever got more than 100% in (40 points extra credit, didn't miss that many during the course of the semester). At the end of the semester, they unplugged the machine and threw it away, and stopped offering that course. GCC used to produce output for that machine. Current versions no longer support it, because no running instances of it still exist outside of museums. I'm not particularly bothered by this. (The fact I once took a Cobol course and got an "A" doesn't mean I'm interested in adding any new cobol to the world, either.) > >But right now, the Linux kernel makes extensive use of gcc extensions, > >and only builds with gcc. > > Does that make it right, or admirable? The Linux kernel is admirable for other reasons. This means "it's a known problem with which we can presumably cope, since they already do". > Has gcc reached the point > yet where it can only be built with itself? Not really something > to be proud of! I'm guessign you're unaware that I maintained a fork of Fabrice Bellard's "tiny C compiler" for almost two years because I was trying to come up with a GCC replacement capable of building the Linux kernel. Here's a video of me hosting a compiler BOF at the most recent Ottawa Linux Symposium where I talk about the ongoing search for a decent open source gcc replacement compiler, what the criteria are, the then-current status of the various contenders, and so on: http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux- compiler.ogg And it is from this perspective I state my belief that compilers which can't do simple dead code elimination are not relevant to modern C99 programs. > >You're sounding _remarkably_ uniformed. > > Perhaps I am, considering that I am a hardware engineer trapped > in a software world. (For the second time). But, Sir, consider > this my apology for having offended your tender sensibilities merely > by expressing an opinion. An opinion clearly marked as such. I'm not offended, I just strongly disagree. > (I have others, regarding some current 'standard' practices that > I don't think are as hot as they are made out to be. I'll be happy > to save those for another time and/or place.) > > I use gotos, and #ifdefs, where appropriate, and I'm proud of it; > White Papers be damned. Gotos are fine. They're C's way to break out of nested loops, and are a useful way of collating exit cleanup code for error handling purposes. Again, the Linux kernel is full of gotos, and is a good model for how to use them properly. :) > -- Jim Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
