德国开元华人社区开元周游

标题: [news] Linus' First Analysis of the Files [打印本页]

作者: cyan 时间: 23.12.2003 12:10
Linus' First Analysis of the Files Monday, December 22 2003 @ 05:41 PM EST Linus has taken a quick look at the files and has given permission for us to publish his first analysis. There will be more to say later, but the bottom line is that SCO appears to have made a copyright claim to some files that Linus wrote himself. I'll let him tell you about it, by reproducing his initial email to me from earlier today. *************************************************************** I have a very strong memory of having written the original "errno.h" myself too, and I really think that at least the i386 version of errno.h actually has different numbers from "real UNIX". Some of the first ones match, but not the rest. That one I explain by just having a list of error codes, and just giving numbers in order, but maybe I'm wrong. I have this distinct memory of figuring out only later that I _should_ have made the numbers be the same, so that I could have been binary compatible. After all, I do actually have the book "Intel386 Family Binary Compatibility Specification 2" (copyright Intel corporation, btw, not SCO), and it lists the error numbers right there. They are different from what Linux uses on x86. Other architectures fixed that mistake, but the point is that the history of "errno.h" is definitely _not_ from UNIX sources. Linus ----- For example, SCO lists the files "include/linux/ctype.h" and "lib/ctype.h", and some trivial digging shows that those files are actually there in the original 0.01 distribution of Linux (ie September of 1991). And I can state - I wrote them (and looking at the original ones, I'm a bit ashamed: the "toupper()" and "tolower()" macros are so horribly ugly that I wouldn't admit to writing them if it wasn't because somebody else claimed to have done so <img src='http://210.51.184.178/kaiyuan/modules/ipboard/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /> - writing them is no more than five minutes of work (you can verify that with any C programmer, so you don't have to take my word for it) - the details in them aren't even the same as in the BSD/UNIX files (the approach is the same, but if you look at actual implementation details you will notice that it's not just that my original "tolower/toupper" were embarrassingly ugly, a number of other details differ too). In short: for the files where I personally checked the history, I can definitely say that those files are trivially written by me personally, with no copying from any UNIX code _ever_. So it's definitely not a question of "all derivative branches". It's a question of the fact that I can show (and SCO should have been able to see) that the list they show clearly shows original work, not "copied". Analysis of "lib/ctype.c" and "include/linux/ctype.h". First, some background: the "ctype" name comes "character type", and the whole point of "ctype.h" and "ctype.c" is to test what kind of character we're dealing with. In other words, those files implement tests for doing things like asking "is this character a digit" or "is this character an uppercase letter" etc. So you can write thing like if (isdigit©) { .. we do something with the digit .. and the ctype files implement that logic. Those files exist (in very similar form) in the original Linux-0.01 release under the names "lib/ctype.c" and "include/ctype.h". That kernel was released in September of 1991, and contains no code except for mine (and Lars Wirzenius, who co-wrote "kernel/vsprintf.c"). In fact, you can look at the files today and 12 years ago, and you can see clearly that they are largely the same: the modern files have been cleaned up and fix a number of really ugly things (tolower/toupper works properly), but they are clearly incremental improvement on the original one. And the original one does NOT look like the unix source one. It has several similarities, but they are clearly due to: - the "ctype" interfaces are defined by the C standard library. - the C standard also specifies what kinds of names a system library interface can use internally. In particular, the C standard specifies that names that start with an underscore and a capital letter are "internal" to the library. This is important, because it explains why both the Linux implementation _and_ the UNIX implementation used a particular naming scheme for the flags. - algorithmically, there aren't that many ways to test whether a character is a number or not. That's _especially_ true in C, where a macro must not use it's argument more than once. So for example, the "obvious" implementation of "isdigit()" (which tests for whether a character is a digit or not) would be #define isdigit(x) (<img src='http://210.51.184.178/kaiyuan/modules/ipboard/html/emoticons/girl_handsacrossamerica.gif' border='0' style='vertical-align:middle' alt='girl_handsacrossamerica.gif' /> >= '0' && <img src='http://210.51.184.178/kaiyuan/modules/ipboard/html/emoticons/girl_handsacrossamerica.gif' border='0' style='vertical-align:middle' alt='girl_handsacrossamerica.gif' /> <= '9') but this is not actually allowed by the C standard (because 'x' is used twice). This explains why both Linux and traditional UNIX use the "other" obvious implementation: having an array that describes what each of the possible 256 characters are, and testing the contents of that array (indexed by the character) instead. That way the macro argument is only used once. The above things basically explain the similarities. There simply aren't that many ways to do a standard C "ctype" implementation, in other words. Now, let's look at the _differences_ in Linux and traditional UNIX: - both Linux and traditional unix use a naming scheme of "underscore and a capital letter" for the flag names. There are flags for "is upper case" (_U) and "is lower case" (_L), and surprise surprise, both UNIX and Linux use the same name. But think about it - if you wanted to use a short flag name, and you were limited by the C standard naming, what names _would_ you use? Maybe you'd select "U" for "Upper case" and "L" for "Lower case"? Looking at the other flags, Linux uses "_D" for "Digit", while traditional UNIX instead uses "_N" for "Number". Both make sense, but they are different. I personally think that the Linux naming makes more sense (the function that tests for a digit is called "isdigit()", not "isnumber()"), but on the other hand I can certainly understand why UNIX uses "_N" - the function that checs for whether a character is "alphanumeric" is called "isalnum()", and that checks whether the character is a upper case letter, a lower-case letter _or_ a digit (aka "number"). In short: there aren't that many ways you can choose the names, and there is lots of overlap, but it's clearly not 100%. - The original Linux ctype.h/ctype.c file has obvious deficiencies, which pretty much point to somebody new to C making mistakes (me) rather than any old and respected source. For example, the "toupper()/tolower()" macros are just totally broken, and nobody would write the "isascii()" and "toascii()" the way they were written in that original Linux. And you can see that they got fixed later on in Linux development, even though you can also see that the files otherwise didn't change. For example: remember how C macros must only use their argument once (never mind why - you really don't care, so just take it on faith, for now). So let's say that you wanted to change an upper case character into a lower case one, which is what "tolower()" does. Normal use is just a fairly obvious newchar = tolower(oldchar); and the original Linux code does extern char _ctmp; #define tolower© (_ctmp=c,isupper(_ctmp)?_ctmp+('a'+'A'):_ctmp) which is not very pretty, but notice how we have a "temporary character" _ctmp (remember that internal header names should start with an underscore and an upper case character - this is already slightly broken in itself). That's there so that we can use the argument "c" only once - to assign it to the new temporary - and then later on we use that temporary several times. Now, the reason this is broken is - it's not thread-safe (if two different threads try to do this at once, they will stomp on each others temporary variable) - the argument © might be a complex expression, and as such it should really be parenthesized. The above gets several valid (but unusual) expressions wrong. Basically, the above is _exactly_ the kinds of mistakes a young programmer would make. It's classic. And I bet it's _not_ what the UNIX code looked like, even in 1991. UNIX by then was 20 years old, and I _think_ that it uses a simple table lookup (which makes a lot more sense anyway and solves all problems). I'd be very susprised if it had those kinds of "beginner mistakes" in it, but I don't actually have access to the code, so what do I know? (I can look up some BSD code on the web, it definitely does _not_ do anythign like the above). The lack of proper parenthesis exists in other places of the original Linux ctype.h file too: isascii() and toascii() are similarly broken. In other words: there are _lots_ of indications that the code was not copied, but was written from scratch. Bugs and all. Oh, another detail: try searching the web (google is your friend) for "_ctmp". It's unique enough that you'll notice that all the returned hits are all Linux-related. No UNIX hits anywhere. Doing a google for _ctmp -linux shows more Linux pages (that just don't happen to have "linux" in them), except for one which is the L4 microkernel, and that one shows that they used the Linux header file (it still says "_LINUX_CTYPE_H" in it). So there is definitely a lot of proof that my ctype.h is original work.

欢迎光临德国开元华人社区开元周游 (https://forum.kaiyuan.de/)

德国开元华人社区 开元周游

德国开元华人社区开元周游