* Re: hmm..
2003-12-22 20:10 hmm John Dee
@ 2003-12-22 21:31 ` Linus Torvalds
2003-12-22 23:10 ` hmm bert hubert
` (2 more replies)
2003-12-22 23:12 ` hmm Gene Heskett
1 sibling, 3 replies; 8+ messages in thread
From: Linus Torvalds @ 2003-12-22 21:31 UTC (permalink / raw)
To: John Dee; +Cc: linux-kernel
On Mon, 22 Dec 2003, John Dee wrote:
>
> I know you guys have already probably seen this.. figured I'd share with
> the class, so the big kids can tear it apart.
> http://lwn.net/Articles/64052/
I spent half an hour tearing part of it apart for some journalists. No
guarantees for the full accuracy of this write-up, and in particular I
don't actually have "original UNIX" code to compare against, but the files
I checked (ctype.[ch]) definitely do not have any UNIX history to them.
The rest of the files are mostly errno.h/signal.h/ioctl.h (and they are
apparently the 2.4.x versions, before we moved some common constants into
"asm-generic/errno.h"), and while I haven't analyzed them, I know for a
fact that
- the original errno.h used different error numbers than "original UNIX"
I know this because I cursed it later when it meant that doing things
like binary emulation wasn't as trivial - you had to translate the
error numbers.
- same goes for "signal.h": while a lot of the standard signals are well
documented (ie "SIGKILL is 9"), historically we had lots of confusion
(ie I think "real UNIX" has SIGBUS at 10, while Linux didn't originally
have any SIGBUS at all, and later put it at 7 which was originally
SIGUNUSED.
So to me it looks like
- yes, Linux obviously has the same signal names and error number names
that UNIX has (so the files certainly have a lot of the same
identifiers)
- but equally clearly they weren't copied from any "real UNIX".
(Later, non-x86 architectures have tried harder to be binary-compatible
with their "real UNIX" counter-parts, and as a result we have different
errno header files for different architectures - and on non-x86
architectures the numbers will usually match traditional UNIX).
For example, doing a "grep" for SIGBUS on the kernel shows that most
architectures still have SIGBUS at 7 (original Linux value), while alpha,
sparc, parisc and mips have it at 10 (to match "real UNIX").
What this tells me is that the original code never came from UNIX, but
some architectures later were made to use the same values as UNIX for
binary compatibility (I know this is true for alpha, for example: being
compatible with OSF/1 was one of my very early goals in that port).
In other words, I think we can totally _demolish_ the SCO claim that these
65 files were somehow "copied". They clearly are not.
Which should come as no surprise to people. But I think it's nice to see
just _how_ clearly we can show that SCO is - yet again - totally
incorrect.
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 ;)
- 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(c)) {
.. 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) ((x) >= '0' && (x) <= '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(c) (_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 (c) 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.
^ permalink raw reply [flat|nested] 8+ messages in thread