Date: Tue, 19 Sep 1995 14:28:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@rocky.sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@rocky.sri.MT.net, davidg@root.com, hackers@freefall.freebsd.org Subject: Re: Coding style ( was Re: why is this not a bug in namei?) Message-ID: <199509192128.OAA10722@phaeton.artisoft.com> In-Reply-To: <199509192049.OAA25811@rocky.sri.MT.net> from "Nate Williams" at Sep 19, 95 02:49:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > He pulled the number 3 out of the air based on his religion in this regard. > > No, I think that *ANY* # of gotos obfuscate things, but sometimes a > single goto is less obfuscation (is that a word?) than other choices. This is opinion. It has been noted. I don't agree with it. > > This is a problem in the general applicability of the specification. Many > > kernel functions return an errno value. > > Fair enough. In those cases it is acceptable to return a different > errno to designate a different error. But, the issue you brought up was > that it is necessary to use gotos in order to maintain one exit point. > My point was using gotos to keep one exit point is un-necessary > obfuscation. OK; this deserves clarification. Is it the goto's themselves which you object to, or their use to ensure a single exit point that is objectionable? If the goto's, then in some cases I agree with you, though I find them the lessor of two evils when choosing between drastically increasing indentation and using negative logic or adding a single label and using a goto. This is admittedly a religious issue (like 8 column tabs -- 4 column tabs would resolve the schizm by reducing the indentation, but it seems that your pope and my pope agree on 8 column tabs saving an average of 1.6 characters per line (4 vs. 3 every other line)). If you can point to the-one-true-light, I'll follow it. If on the other hand, you are objecting to the need for single entry/exit, I can justify this in terms of adding kernel multithreading and SMP locks in such a way as to cause them to "go away" in the Uniprocessor or non multithreading case. It should be noted that USL was able to get a 60% performance improvement out of UFS in the Uniporcessor case, even taking the extra locking into account, by kernel multithreading. > As I understand it, the specification quoted above was meant to be > applied to application programs who 'exit'. I used it to show that > there was no documentation which implied one exit point from a function. > I'm not sure where you got this feeling from. I got it from the need to have known state in and out of a function and to maintain that state across changes to the function body. It's difficult to maintain consistency without explicit assertions, and multiplying the exit points multiplies the chances that you will introduce an inconsistency when modifying function bodies. For file system modules, it's possible to enforce state through assertions at the VOP_ layer of inline functions. Unfortuantely, for things like system call trap vectors (and especially the longjmp() out on an interrupt of a system call in the trap code), without single entry/exit, it's near impossible to unwind the additional lock state correctly and consistently, especially with multiple programmers going into that code. I think this makes a good case for single entry/exit, no matter if it is implemented via goto's or negative logic or local stack variables that contain state bitmaps, or whatever. The benefits of kernel multithreading should be obvious. Don't tell me you believe that the BSDI version of Netscape's HotJava port is going to run on FreeBSD without kernel threading support? Single entry/exit is a tool I need to be able to work on the issues of kernel reentrancy, whether it's caused by internal multithreading or a second processor coming in on a system call or interrupt is really not relevant. If you can work on the problem without that tool, fine: do it. > > If this is a form vs. function argument now, then I have already won, > > since you also seem to be on the side of function. > > No, I'm saying that *IF* you are going to re-write the code, write it in > such a manner that makes it understandable. And I'm saying, adding a goto to an error label is not obfuscating the code into unreadability. It is clearly an error path and clearly an exception case. As I said before, point to the-one-true-light, and I'll follow it. > Modifying the code from a dis-functional but readable form into a > functional but un-readable form is not progress. I agree. The closes I've come to that, as I said before, is SYSINIT. I made it plain at the time I submitted the code that the order of operation was documented in the enumerated type code in kernel.h, and that it was not expected to be changed frequenetly, but that some overall kernel documentation on the order of the Dameon book should probably be assembled. There is *nothing* more obfusacted in the kernel than the return from the creation of the init process to the assembly language caller of the main(). I pointed out that what is wanted is the export of a function label that gets called instead of having that return happen. > First of all, someone has to own the code in the CVS tree, and if > they don't understand it at some level, they are not going to commit it. Fine. Come up with a more readable alternative than a goto in error cases to an error label and no goto in non-error cases except where massive function reordering would be necessary. > Second of all, IMHO most of the bugs in the system exist in areas where > the code is not extremely readable. I agree. Like the HASBUF/SAVENAME/SAVESTART crap in namei() and each VOP_ lookup and each VOP_ call that deals with directory entry manipulation. I'd like to clean that up, if only people would let me. Sheesh! > I've seen too many systems where 'form' was not followed and > functionality ruled, and when the person who implemented the > 'functionality' left the code continued to live on bugs and all since > no-one else understood it. > > Let's strive for both form and function. I don't believe adding a goto translates a program into Sanskrit. Tell you what. I'll teach you how to read a goto. Then you can carry on when I get hit by a car on my way home some night by some anti-goto zealot. After my martyrdom, you can expand the teaching, and all programmers everywhere will one day understand the language constructs of the languages in which they program. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509192128.OAA10722>