SCO's infringing files list
Guys,
According to the totally inept, idiotic, SCO group, these files are copyrighted by them (and recently by Novell I might add):
include/asm-alpha/errno.h
include/asm-arm/errno.h
include/asm-cris/errno.h
include/asm-i386/errno.h
include/asm-ia64/errno.h
include/asm-m68k/errno.h
include/asm-mips/errno.h
include/asm-mips64/errno.h
include/asm-parisc/errno.h
include/asm-ppc/errno.h
include/asm-ppc64/errno.h
include/asm-s390/errno.h
include/asm-s390x/errno.h
include/asm-sh/errno.h
include/asm-sparc/errno.h
include/asm-sparc64/errno.h
include/asm-x86_64/errno.h
include/asm-alpha/signal.h
include/asm-arm/signal.h
include/asm-cris/signal.h
include/asm-i386/signal.h
include/asm-ia64/signal.h
include/asm-m68k/signal.h
include/asm-mips/signal.h
include/asm-mips64/signal.h
include/asm-parisc/signal.h
include/asm-ppc/signal.h
include/asm-ppc64/signal.h
include/asm-s390/signal.h
include/asm-s390x/signal.h
include/asm-sh/signal.h
include/asm-sparc/signal.h
include/asm-sparc64/signal.h
include/asm-x86_64/signal.h
include/linux/stat.h
include/linux/ctype.h
lib/ctype.c
include/asm-alpha/ioctl.h
include/asm-alpha/ioctls.h
include/asm-arm/ioctl.h
include/asm-cris/ioctl.h
include/asm-i386/ioctl.h
include/asm-ia64/ioctl.h
include/asm-m68k/ioctl.h
include/asm-mips/ioctl.h
include/asm-mips64/ioctl.h
include/asm-mips64/ioctls.h
include/asm-parisc/ioctl.h
include/asm-parisc/ioctls.h
include/asm-ppc/ioctl.h
include/asm-ppc/ioctls.h
include/asm-ppc64/ioctl.h
include/asm-ppc64/ioctls.h
include/asm-s390/ioctl.h
include/asm-s390x/ioctl.h
include/asm-sh/ioctl.h
include/asm-sh/ioctls.h
include/asm-sparc/ioctl.h
include/asm-sparc/ioctls.h
include/asm-sparc64/ioctl.h
include/asm-sparc64/ioctls.h
include/asm-x86_64/ioctl.h
include/linux/ipc.h
include/linux/acct.h
include/asm-sparc/a.out.h
include/linux/a.out.h
arch/mips/boot/ecoff.h
include/asm-sparc/bsderrno.h
include/asm-sparc/solerrno.h
include/asm-sparc64/bsderrno.h
include/asm-sparc64/solerrno.h
Any thoughts?
-sb
Quoted 1 line
Any thoughts?
Yep. After a very partial and preliminary look (ctype.h, signal.h, errno.h)
I would recommend that SCO sue the much larger pot of Microsoft Windows users out there.
So far as I can tell, Visual Studio ships with these files as well, although
I can't compare the Linux, SCO, and Windows versions of them.
Anyone with more info?
-Joseph
Signature · 2 lines
Joseph===============================================trelane@digitasaru.net
Graduate Student in Physics, Freelance Free Software DeveloperQuoted 11 lines · Joseph Pingenot
Quoted 1 line
Any thoughts?
Yep. After a very partial and preliminary look (
ctype.h,signal.h,errno.h)
I would recommend that SCO sue the much larger pot of Microsoft Windows users out there.
So far as I can tell, Visual Studio ships with these files as well, although
I can't compare the Linux, SCO, and Windows versions of them.
Anyone with more info?-Joseph
SCO contends that as part of BSD settlement these files must retain a System V copyright header...unfortunately for them that settlement onyl affected BSD and no one else, and the judge made clear it didn't believe USL held the copyrights to these files sine they were previously released without a copyright statement.
Furthermore the private settlement still isn't public so their claims are beyond dubious, they fall into fraudulent at this point. These files have been published in books and elsewhere... and are mostly defines, no code or methods...
Looks bleak for them, as long as the press doesn't jsut use this to keep backing SCO as heros...god it makes me sick...in any other country these fiends would be behind bars for trying extort money for things they don't own and haven't proven they own. Swindlers.
Come on SEC, step up you quivering cowards.
-sb
Quoted 10 lines · Stan Bubrouski
Guys,
According to the totally inept, idiotic, SCO group, these files are copyrighted by them (and recently by Novell I might add):
include/asm-i386/errno.hAny thoughts?
-sb
The original errno.h, from linux-0.01, says it was taken from minix, and goes up to 40. Between linux-0.96c and linux-0.97, that file was replaced with the present version, which includes the error strings and goes up to 121.
Where did the 0.97 to present version come from?
Signature · 5 lines
Tom Felker, <[email protected]> <http://vlevel.sourceforge.net> - Stop fiddling with the volume knob. Everything else about computers has become cheaper and faster. Why not software?
Quoted 3 lines · Tom Felker
The original
errno.h, from linux-0.01, says it was taken from minix, and goes up to 40.
Good eyes - I only analysed the ctype.h thing, and didn't look up errno.h in the original sources. errno.h has a _big_ comment saying where the numbers came from (and some swearwords about POSIX ;)
Looking at signal.h, those numbers also seem to largely match minix. Which makes sense - I actually had access to them.
In both cases it's only the numbers that got copied, though. And not all of them either - for some reason I tried to make the signal numbers match (probably lazyness - not so much that I cared about the numbers themselves, but about the list of signal names), but for example the SA_xxxx macros - in the very same file - bear no relation to the minix ones.
Linus
Quoted 14 lines · Linus Torvalds
Quoted 3 lines · Tom Felker
The original
errno.h, from linux-0.01, says it was taken from minix, and goes up to 40.Good eyes - I only analysed the
ctype.hthing, and didn't look uperrno.hin the original sources.errno.hhas a _big_ comment saying where the numbers came from (and some swearwords about POSIX ;)Looking at
signal.h, those numbers also seem to largely match minix. Which makes sense - I actually had access to them.
Quoted 6 lines
In both cases it's only the numbers that got copied, though. And not all of them either - for some reason I tried to make the signal numbers match (probably lazyness - not so much that I cared about the numbers themselves, but about the list of signal names), but for example the
SA_xxxxmacros - in the very same file - bear no relation to the minix ones.
And for the names, perhaps they would care to sue The Open Group?
http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
And that probably applies to the rest of these header files.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
Quoted 4 lines · jw schultz
And for the names, perhaps they would care to sue The Open Group?
http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
And that probably applies to the rest of these header files.
Just to shore up what jw was talking about:
http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/ctype.h.html
and for a listing of all the defines the open group has (dir listing):
http://www.opengroup.org/onlinepubs/007904975/basedefs/
Best Regards,
sb
Quoted 2 lines · jw schultz
And for the names, perhaps they would care to sue The Open Group?
Not the names, but the comments. 8-)
The comments were added in Linux 0.99.1, and I'm not sure what was the source. For example, Linux has:
#define ENOTTY 25 /* Not a typewriter */
Solaris:
#define ENOTTY 25 /* Inappropriate ioctl for device */
Current POSIX:
[ENOTTY]
Inappropriate I/O control operation.
I couldn't find any historic Minix header files. Minix 2 has:
#define ENOTTY (_SIGN 25) /* inappropriate I/O control operation */
Quoted 22 lines · Florian Weimer
Quoted 2 lines · jw schultz
And for the names, perhaps they would care to sue The Open Group?
Not the names, but the comments. 8-)
The comments were added in Linux 0.99.1, and I'm not sure what was the source. For example, Linux has:
#define ENOTTY 25 /* Not a typewriter */
Solaris:
#define ENOTTY 25 /* Inappropriate ioctl for device */
Quoted 8 lines
Current POSIX:
[ENOTTY]
Inappropriate I/O control operation.I couldn't find any historic Minix header files. Minix 2 has:
#define ENOTTY (
_SIGN25) /* inappropriate I/O control operation */
In http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c
/* Extended support for using errno values.
Written by Fred Fish. [email protected]
This file is in the public domain. --Per Bothner. */
(...)
#if defined (ENOTTY)
ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
#endif
FYI there was a proposed patch to change "Not a typewriter" to "Inappropriate ioctl for device". Check the interesting thread of lkml:
http://www.ussg.iu.edu/hypermail/linux/kernel/0105.1/0471.html
ciao
giacomo
Quoted 4 lines · Giacomo A. Catenazzi
Quoted 3 lines · Florian Weimer
The comments were added in Linux 0.99.1, and I'm not sure what was the source.
No, the comments are already there in 0.97 (and they are _not_ in 0.96c-pl2, which is the last patch before that that I have found).
The timeline looks like (this is by no means guaranteed correct, the dates are from things like the patch files that may not be the originals, but they look consistent):
0.96c: July 4th, 1992
0.96c-pl1: July 11th
0.96c-pl2: July 18th
--- here somewhere ---
0.97: Aug 1st
The errno change was apparently done on or around July 25, 1992. That's the date on the "errno.h" file in the linux-0.97 archive, and it is consistent with the above release dates.
If anybody has newgroup/mailing list archives from around that time, it would be very nice to see what that finds..
Quoted 3 lines
Quoted 3 lines
For example, Linux has:
#define ENOTTY 25 /* Not a typewriter */
My _suspicion_ is that it comes from "strerror()". That's how I'd personally have done it (ie write a simple script to generate the errno values and the comments). But this is over a decade ago, and I sure as hell can't remember who would have done that.
It might even have been me, but I doubt it - I've never been that big into comments, so it's likely somebody else was more motivated than me to make errno.h cleaner. But if I did it, I definitely would have done it with a script.
Btw: there is some incidental "evidence" that that original 0.97 version of <linux/errno.h> is automatically generated: the thing looks to have very regular whitespace. It looks like it was generated with
#define\t%s\t\t%2d\t/* %s */
and then tab-corrected for the symbolic name lengths. There are no spaces at ends-of-lines, and _all_ of the spaces between "define" and the actual error mnemonic are actually _tabs_.
And this is true for _all_ the Exxxx defines _except_ for the two special kernel entries: ERESTARTSYS and ERESTARTNOINTR were clearly not generated the same way, because they have a regular _space_ between the #define and the EXXXX.
That just makes me go "hmm..". You can't actually see the TAB vs <space> thing when you open the file normally, because they both end up being aligned the same way. So I'd suspect a script that generated the list of the "normal" error codes simply because
- people just aren't that regular by hand
- most people would use a space in between #define and XXXX, as also shown by the two cases that clearly are _not_ scripted.
For example, grepping for "#define" followed by space shows up 1836 such entries in the 0.97 kernel. In contrast, doing the same for "#define" followed by a tab shows 227 such entries - of which the errno.h ones are a solid block of 121 entries, while the others are a lot more random (and 44 of the remaining ~100 cases have multiple tabs and are thus _visible_ as such).
So just from a regularity standpoint, it does look auto-generated.
Quoted 4 lines
Quoted 4 lines
Solaris:
#define ENOTTY 25 /* Inappropriate ioctl for device */
Quoted 8 lines
Quoted 8 lines
Current POSIX:
[ENOTTY]
Inappropriate I/O control operation.I couldn't find any historic Minix header files. Minix 2 has:
#define ENOTTY (
_SIGN25) /* inappropriate I/O control operation */
The "Not a typewriter" thing is the obvious one from just reading the error number mnemonic. Hard to tell where it comes from, but it definitely does not rule out strerror() in that timeframe.
Quoted 10 lines
In
http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c/* Extended support for using errno values.
Written by Fred Fish. [email protected]
This file is in the public domain. --Per Bothner. */
(...)
#if defined (ENOTTY)
ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
#endif
Something like that may well be the source of the string. Fred Fish was active long before this timeframe (if it's the same Fred Fish - he used to do freeware collections for the Amiga in the '80's).
But there were multiple libc's around (estdio, libc5, glibc..), and it could be any of them.
Trying to find the kernel list archives from that timeframe would likely clarify the issue. There were several lists back then: "linux-activists" mailing list, and of course the "comp.os.linux" newsgroup (this was before it split into multiple newsgroups).
I've found some archives for linux-activists, but no newsgroup archives going that far back.. Anybody?
Linus
Quoted 7 lines · Linus Torvalds
Trying to find the kernel list archives from that timeframe would likely clarify the issue. There were several lists back then: "linux-activists" mailing list, and of course the "comp.os.linux" newsgroup (this was before it split into multiple newsgroups).
I've found some archives for linux-activists, but no newsgroup archives going that far back.. Anybody?
http://groups.google.com/advanced_group_search
They'd done what DN had promised and never did - merged old usenet archives into their database, all way back to '81.
The earliest they have on comp.os.linux is March 1992 and results of voting on newgroup had been posted by tytso on Mar 25 1992. There's a bogus crosspost into (still not existing) c.o.l on Mar 21 and regular postings starting on Mar 31. IOW, archive goes all way back to the group creation.
alt.os.linux archives there start on Jan 19 1992 (newgrouped somewhere around Jan 17, took several days to propagate). Before that it's c.o.minix, but by the time you are looking for migration from c.o.m should've been over.
Quoted 15 lines · Linus Torvalds
Quoted 9 lines · Giacomo A. Catenazzi
In http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c
/* Extended support for using errno values.
Written by Fred Fish. [email protected]
This file is in the public domain. --Per Bothner. */
(...)
#if defined (ENOTTY)
ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
#endifSomething like that may well be the source of the string. Fred Fish was active long before this timeframe (if it's the same Fred Fish - he used to do freeware collections for the Amiga in the '80's).
Quoted 7 lines
But there were multiple libc's around (estdio, libc5, glibc..), and it could be any of them.
Trying to find the kernel list archives from that timeframe would likely
clarify the issue. There were several lists back then: "linux-activists" mailing list, and of course the "comp.os.linux" newsgroup (this was before it split into multiple newsgroups).I've found some archives for linux-activists, but no newsgroup archives going that far back.. Anybody?
I found only a mail in linux-activists: It say """
4. lots of stuffs added to errno.h and string/errlist.c.
"""
It seems that the new errno.h is added in libc, but there are some references of kernel and the post date is in the same weeks of the new kernel errno.h, so possibly the linux errno.h is based uppon this library. Maybe someone of the "old" guys will understand something better about this post.
ciao
giacomo
From: [email protected] (H.J. Lu)
Subject: Re: gcc-2.2.2 patches for linux?
Date: 19 Jul 92 15:42:48 GMT
In article <[email protected]> [email protected] (Clarence Wilkers
Quoted 3 lines · on)
I'd like to do cross compilation for linux on a sparc. Has anyone set this up?
--
Please read all the previous release notes and docs. This release note only covers the new stuffs.
This is gcc 2.2.2 for Linux. It is on banjo.concert.net under /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS. The FSF has all the files Linux needs.
Please get the new binutils.tar.Z, which fixed some bugs in as and a gprof with some patches from Rick Sladkey at [email protected], if you haven't got it.
I added some jumptable stubs to gcc. But I don't have the time to implement it. In the future, you can use jump table with -jump in CFLAGS.
Libg++.a is 2.2 beta.
This gcc will produce binaries only run safely under 0.96a patch level 4 or above.
The list of known bugs.
1. one 'cmp' in dbz test fails. Per is not planning on doing anything about it. your contribution is welcome.
The following bugs in libc.a are fixed.
1. hard and soft math libs are fixed. some of functions are totally rewritten.
2. acosh, asinh and atanh are added to libsoft.a and math.h.
3. open a file for read and write, then do fseek followed by fwrite works now.
4. now random () and srandom () are renamed to __random () and __srandom (), respectively.
5. the header files taken from glibc.a are fixed.
6. the sys call mount now takes 4 args.
7. getpagesize and getdtablesize work now.
8. netdb.h, resolv.h, sys/uio.h, netinet.h, arpa/inet.h and arpa/nameser.h are changed.
9. Some function declarations are added to sys/socket.h in 0.96bp2inc.tar.Z.
The following functions are added to libc.a.
1. profil.
2. libg.a is there.
3. getdtablesize.
4. lots of stuffs added to errno.h and string/errlist.c.
5. some changes in string/siglist.c.
6. dtoa.
7. there is a new strtod, please check it out.
8. drem.
9. the inet library functions are in libinet.a. They are untested. Once they are tested ok, they will be moved to libc.a. All the inet library functions are there, except for res_xxxx, rcmd, rexec and ruserpass, which require more kernel support, like F_SETOWN, FASYNC, and a few network system calls.
There should also be a set of files in /etc for inet functions. I hope Ross will provide them.
In this release, there is a libc_p.a compiled with "-pg" for profiling.
You should use "-g" for debugging and "-pg/-p" for profiling in CFLAGS when you compile the source code.
There must be a few other bugs. Please let me know if you find any.
File list:
1. 2.2.2db.tar.Z (cpp, libg.a and libc_p.a)
2. 2.2.2lib.tar.Z (cc1, cc1plus)
3. 2.2.2misc.tar.Z (header files, drivers, libs, doc, ....)
4. shlib-2.2.2.tar.Z (making the shared libs for gcc 2.2.2)
5. libc-2.2.2.tar.Z (source code for the libs)
6. gcc-2.2.2.tar.Z (patches for compiling gcc 2.2.2)
7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)
H.J.
[email protected]
06/27/92
Quoted 2 lines · Giacomo A. Catenazzi
I found only a mail in linux-activists: It say """
4. lots of stuffs added toerrno.handstring/errlist.c.
Yeah, I just found that one too - its in digest485 from the tarball
http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux-activists/Volume2/Linux-V2-4XX.tar.z
| From: [email protected] (H.J. Lu) | Subject: Re: gcc-2.2.2 patches for linux? | Date: 19 Jul 92 15:42:48 GMT | [...] | This is gcc 2.2.2 for Linux. It is on banjo.concert.net under | /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS. The FSF | has all the files Linux needs.
Note that this is back when gcc and libc were distributed together, both by H J Lu. The file list in the announcement includes:
| 1. 2.2.2db.tar.Z (cpp, libg.a and libc_p.a) | 2. 2.2.2lib.tar.Z (cc1, cc1plus) | 3. 2.2.2misc.tar.Z (header files, drivers, libs, doc, ....) | 4. shlib-2.2.2.tar.Z (making the shared libs for gcc 2.2.2) | 5. libc-2.2.2.tar.Z (source code for the libs) | 6. gcc-2.2.2.tar.Z (patches for compiling gcc 2.2.2) | 7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)
The last file seems to be a modified version of the 0.96bp2 header files needed in order to work with the new gcc release (searching for that filename turns up a message discussing it a little) So I'm guessing that the July 25, 1992 errno.h in the linux tree is a merge from this code.
Now, does anyone have a copy of "0.96bp2inc.tar.Z" lying around?
-Mitch
Quoted 5 lines · I wrote:
| 7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)
The last file seems to be a modified version of the 0.96bp2 header files needed in order to work with the new gcc release (searching for that filename turns up a message discussing it a little)
This does seem to be the case - from an FAQ that H J Lu posted about that time:
| From: [email protected] (H.J. Lu) | Subject: FAQ about gcc (how to compile program under Linux) | Date: Sun, 19 Jul 92 06:40:05 GMT | [...] | Another file, XXXXinc.tar.Z, where XXXX is the current version number | of Linux kernel, has all the header files to replace the header files | from kernel. YOU MUST INSTALL IT. Please read README for details.
There is some mention of a "GCC channel" where new linux GCC releases got discussed:
| If you want to use the testing release, first | join the GCC channel on the Linux mailing list, and then send a note to | [email protected].
Does anyone know if there's an archive available for that ancient list? Maybe we can find some discussion WRT errno.h there.
-Mitch
Bingo!
Quoted 10 lines · Mitchell Blank Jr
This does seem to be the case - from an FAQ that H J Lu posted about that time:
| From: [email protected] (H.J. Lu) | Subject: FAQ about gcc (how to compile program under Linux) | Date: Sun, 19 Jul 92 06:40:05 GMT | [...] | Another file, XXXXinc.tar.Z, where XXXX is the current version number | of Linux kernel, has all the header files to replace the header files | from kernel. YOU MUST INSTALL IT. Please read README for details.
Ok, this is the source.
In particular, I can re-create _exactly_ the linux-0.97 "errno.h" file by using the "sys_errlist[]" contents from "libc-2.2.2". In particular, this trivial loop will generate the exact (byte-for-byte) list that is in the kernel:
int i;
for (i = 1; i < 122; i++) {
const char *name = names[i];
int n = strlen(name);
char *tabs = "\t\t"+(n > 7);
const char *expl = libc222_errlist[i];
printf("#define\t%s%s%2d\t/* %s */\n",
name, tabs, i, expl);
}here, the "names[]" array was filled in with the error names, ie
const char *names[] = { "none",
"EPERM", "ENOENT", "ESRCH", "EINTR", "EIO", "ENXIO", "E2BIG",
...and the "libc222_errlist[]" array was filled in with the strings found by just downloading the old "libc-2.2.2" binary that can still be found at
http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/
and then just doing a "strings - libc-2.2.2" and "sys_errlist[]" will be obvious:
static char *libc222_errlist[] = {
"Unknown error",
"Operation not permitted",
...This was literally a five-minute hack (I wrote the silly loop yesterday to see what it does with the current "strerror()" - there is very good correlation even today, but using the libc-2.2.2 sys_nerrlist[] you get _exactly_ the same result).
So this is definitely the source of the kernel error header. It's either a file from the libc sources, or it is literally auto-generated like the above (I actually suspect the latter - now that I did the auto-generation it all felt very familiar, but that may just be my brain rationalizing things. Humans are good at rationalizing reality.).
Can anybody find the actual libc _sources_? Not the kernel headers that hjl mentions (those are the old ones from _before_ the change), but the file "libc-2.2.2.tar.Z"?
Anyway, we know where the kernel header comes from. Let's figure out where the libc data comes from.
Linus
Quoted 2 lines · Linus Torvalds
Bingo!
[...]
Quoted 3 lines
Can anybody find the actual libc _sources_? Not the kernel headers that hjl mentions (those are the old ones from _before_ the change), but the file "libc-2.2.2.tar.Z"?
Well, it's been recompressed with gzip, but it's here (among other places):
ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz
I haven't checked the original GNU/MIT site it was apparently mirrored from, but it might be there.
Charles
Signature · 4 lines
----------------------------------------------------------------------- Charles Cazabon <[email protected]> GPL'ed software available at: http://www.qcc.ca/~charlesc/software/ -----------------------------------------------------------------------
Quoted 2 lines · Charles Cazabon
Well, it's been recompressed with gzip, but it's here (among other places):
ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz
No, we're looking for the pre-glibc-2 versions. In the early days of linux the "libc" version was kept in sync with the gcc it was meant to go with. So although (IIRC) the early linux libc was forked from GNU's libc it had its own version numbering. It wasn't until years later that the big merge back to glibc happened (1997 or so).
I don't think you'll find any of the old linux libc-2.x.x releases on GNU's site.
-Mitch
Quoted 10 lines · Charles Cazabon
Quoted 2 lines · Linus Torvalds
Bingo!
[...]
Quoted 3 lines
Can anybody find the actual libc _sources_? Not the kernel headers that hjl mentions (those are the old ones from _before_ the change), but the file "libc-2.2.2.tar.Z"?
Well, it's been recompressed with gzip, but it's here (among other places):
ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz
Completely different animal. glibc2 is at least 5 years later.
Quoted 7 lines · Charles Cazabon
[...]
Quoted 3 lines
Can anybody find the actual libc _sources_? Not the kernel headers that hjl mentions (those are the old ones from _before_ the change), but the file "libc-2.2.2.tar.Z"?
Well, it's been recompressed with gzip, but it's here (among other places):
ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz
Nope. That is something entirely different -- and 9 years latter.. Nor can I find these bits in FUNET.FI's ancient archive branches.
Quoted 8 lines
I haven't checked the original GNU/MIT site it was apparently mirrored from, but it might be there.
Charles
Signature · 3 lines
----------------------------------------------------------------------- Charles Cazabon <[email protected]> GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
Why is everyone looking in FTP sites? Doesn't anyone have those old CDs with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a box somewhere.
Is anyone from (or formerly from) cdrom.com (read|listen)ing?
Quoted 25 lines · Matti Aarnio
Quoted 7 lines · Charles Cazabon
[...]
Quoted 3 lines
Can anybody find the actual libc _sources_? Not the kernel headers that hjl mentions (those are the old ones from _before_ the change), but the file "libc-2.2.2.tar.Z"?
Well, it's been recompressed with gzip, but it's here (among other places):
ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gzNope. That is something entirely different -- and 9 years latter.. Nor can I find these bits in FUNET.FI's ancient archive branches.
Quoted 8 lines
I haven't checked the original GNU/MIT site it was apparently mirrored from, but it might be there.
Charles
Signature · 3 lines
----------------------------------------------------------------------- Charles Cazabon <[email protected]> GPL'ed software available at: http://www.qcc.ca/~charlesc/software/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Shawn
Why is everyone looking in FTP sites? Doesn't anyone have those old CDs with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a box somewhere.
Is anyone from (or formerly from) cdrom.com (read|listen)ing?
I found the original libc-222 sources on an old machine of mine, and I do believe it originally came off of an old FTP a while back (too far back for me to remember off hand). Can be gotten at:
http://www.ccs.neu.edu/~stan/linux/libc-222.taz
That is the only 2.x version of libc I have found thus far, in the same directory I found a bunch of old 4.x and 5.x libc versions as well, if anyone wants a specific one let me know and I'll post it to the site or e-mail it directly (I don't have enough web room to post them all atm). Not sure, but from the looks of the directory structure I must have got them mirroring a site back in '97. Not sure what site though. I'm trying to figure that out to see if its mirrored anywhere else.
Regards,
sb
Quoted 3 lines
Why is everyone looking in FTP sites? Doesn't anyone have those old CDs with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a
There are probably many of us; I checked my old InfoMagic "Developer's Resource" 4 CD set from 1995 and found a 'linux-activists' archive that goes back to November of 1991.
JS
Quoted 3 lines · 500Shawn wrote:
Why is everyone looking in FTP sites? Doesn't anyone have those old CDs with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a box somewhere.
How about "Linux Quarterly Fall 1994" (now includes Slackware Professional 2.1). And sunsite archives. I've also got some CheapBytes "complete Linux" CDs from about the same time.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 62 lines · Linus Torvalds
Bingo!
Quoted 10 lines · Mitchell Blank Jr
This does seem to be the case - from an FAQ that H J Lu posted about that time:
| From: [email protected] (H.J. Lu) | Subject: FAQ about gcc (how to compile program under Linux) | Date: Sun, 19 Jul 92 06:40:05 GMT | [...] | Another file, XXXXinc.tar.Z, where XXXX is the current version number | of Linux kernel, has all the header files to replace the header files | from kernel. YOU MUST INSTALL IT. Please read README for details.Ok, this is the source.
In particular, I can re-create _exactly_ the linux-0.97 "
errno.h" file by using the "sys_errlist[]" contents from "libc-2.2.2". In particular, this trivial loop will generate the exact (byte-for-byte) list that is in the kernel:int i; for (i = 1; i < 122; i++) { const char *name = names[i]; int n = strlen(name); char *tabs = "\t\t"+(n > 7); const char *expl = libc222_errlist[i]; printf("#define\t%s%s%2d\t/* %s */\n", name, tabs, i, expl); }here, the "names[]" array was filled in with the error names, ie
const char *names[] = { "none", "EPERM", "ENOENT", "ESRCH", "EINTR", "EIO", "ENXIO", "E2BIG", ...and the "libc222_errlist[]" array was filled in with the strings found by just downloading the old "libc-2.2.2" binary that can still be found at
http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/and then just doing a "strings - libc-2.2.2" and "sys_errlist[]" will be obvious:
static char *libc222_errlist[] = { "Unknown error", "Operation not permitted", ...This was literally a five-minute hack (I wrote the silly loop yesterday to see what it does with the current "
strerror()" - there is very good correlation even today, but using the libc-2.2.2 sys_nerrlist[] you get _exactly_ the same result).So this is definitely the source of the kernel error header. It's either a file from the libc sources, or it is literally auto-generated like the above (I actually suspect the latter - now that I did the auto-generation it all felt very familiar, but that may just be my brain rationalizing things. Humans are good at rationalizing reality.).
Quoted 8 lines
Can anybody find the actual libc _sources_? Not the kernel headers that hjl mentions (those are the old ones from _before_ the change), but the file "libc-2.2.2.tar.Z"?
Anyway, we know where the kernel header comes from. Let's figure out where the libc data comes from.
Linus
The earliest tarballs here may be of interest:
http://www.pell.portland.or.us/~orc/Code/libc/
[steven@spc9 libc-linux]$ head -n 20 jumptable1/string/_errlist.c #include <ansidecl.h>
#include <stddef.h>
#include <errno.h>
/* This is a list of all known signal numbers. */
CONST char *CONST _sys_errlist[] = {
"Unknown error", /* 0 */
"Operation not permitted", /* EPERM */
"No such file or directory", /* ENOENT */
"No such process", /* ESRCH */
"Interrupted system call", /* EINTR */
"I/O error", /* EIO */
"No such device or address", /* ENXIO */
"Arg list too long", /* E2BIG */
"Exec format error", /* ENOEXEC */
"Bad file number", /* EBADF */
"No child processes", /* ECHILD */
"Try again", /* EAGAIN */
"Out of memory", /* ENOMEM */That file dates from Nov 20 1992.
Steven
Quoted 3 lines · Steven Cole
/* This is a list of all known signal numbers. */
CONST char *CONST _sys_errlist[] = {
Note the incorrect comment (since its a list of error numbers, not signal numbers). It looks like the comment was originally from siglist.c in the same directory.
I wonder if there are any UNIX sources which have a similar typo. I somewhat doubt it.
-Mitch
(Replying to myself again)
Quoted 1 line
Now, does anyone have a copy of "0.96bp2inc.tar.Z" lying around?
BTW, a few more details on this file - the linux GCC 2.2.2 release was originally announced 28-Jun-1992. The 0.96bp2inc.tar.Z file originally lived on the then-primary linux ftp site banjo.concert.net in directory pub/Linux/GCC.
banjo stopped being an FTP server a couple months later - however, Jonathan Magid announced on 13-Aug-1992 that the entire banjo site was being reincarnated at host reggae.oit.unc.edu in directory ftp/pub/pc-stuff/Linux. Here's a copy of the announcement:
http://www.kclug.org/old_archives/linux-activists/1992/aug/1/0708.shtml
My understanding is that reggae.oit morphed at some point into sunsite.unc.edu (which is now, of course, ibiblio.org) Jonathan still appears to be there, so I'm cc:ing him on this (apologies in advance if its an intrusion, Jonathan) on the off-chance that there might still be a 1992-era archive of the linux files once hosted by banjo.
The only other person likely to have access to a copy is H J Lu himself (also cc:'ed although I'm 99% sure he's still on lkml :-)
-Mitch
Quoted 9 lines · Mitchell Blank Jr
(Replying to myself again)
Quoted 1 line
Now, does anyone have a copy of "0.96bp2inc.tar.Z" lying around?
BTW, a few more details on this file - the linux GCC 2.2.2 release was originally announced 28-Jun-1992. The 0.96bp2inc.tar.Z file originally lived on the then-primary linux ftp site banjo.concert.net in directory pub/Linux/GCC.
Note that we really don't care about that "0.96bp2inc.tar.Z" file: that's just the kernel headers, and 0.96b-pl2 did _not_ contain the comments yet. But libc used to use the kernel headers for other things (for things like system call numbers etc).
It's almost certainly the "libc-2.2.2.tar.Z" file that we want - that's the one that is going to contain the sys_errlist[] lists etc. Note how this libc-2.2.2 announcement predates the merging of the kernel header by almost a month - the kernel header information came from libc, not the other way around.
Quoted 5 lines
banjo stopped being an FTP server a couple months later - however, Jonathan Magid announced on 13-Aug-1992 that the entire banjo site was being reincarnated at host reggae.oit.unc.edu in directory ftp/pub/pc-stuff/Linux. Here's a copy of the announcement:
http://www.kclug.org/old_archives/linux-activists/1992/aug/1/0708.shtml
Does anybody have old CD-ROM's lying around?
In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently released just a few months later. It would quite possibly contain the libc-2.2.2 sources... Adam Richter is still active, and I added him to the cc..
Who else was doing CD's back then? SLS? If nobody has the thing on a web-site any more, maybe they exist in physical format on somebodys bookshelf? The only reason that the really historic kernel archives still exist is that people saved them, and even so we're missing versions 0.02 and 0.03, but by the latter half of -92 there were already CD-ROMs being manufactured...
Of course, maybe the CD's are unreadable by now.
Linus
Quoted 5 lines · Linus Torvalds
In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently released just a few months later. It would quite possibly contain the libc-2.2.2 sources... Adam Richter is still active, and I added him to the cc..
Quoted 9 lines
Who else was doing CD's back then? SLS? If nobody has the thing on a web-site any more, maybe they exist in physical format on somebodys bookshelf? The only reason that the really historic kernel archives still exist is that people saved them, and even so we're missing versions 0.02 and 0.03, but by the latter half of -92 there were already CD-ROMs being manufactured...
Of course, maybe the CD's are unreadable by now.
You mean this?
http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/libc.2.2.2.z
-sb
Quoted 7 lines
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Harry McGregor
I believe that is just a binary... :-/
-sb
Quoted 10 lines
Harry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · Harry McGregor
Yep. Thats the binary he's talked repeatedly about already having. Got sources?
Signature · 1 line
Disconnect <[email protected]>
Ignore my last reply, sometimes I'm jsut an idiot.
-sb
Quoted 23 lines · Linus Torvalds
Does anybody have old CD-ROM's lying around?
In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently released just a few months later. It would quite possibly contain the libc-2.2.2 sources... Adam Richter is still active, and I added him to the cc..
Who else was doing CD's back then? SLS? If nobody has the thing on a web-site any more, maybe they exist in physical format on somebodys bookshelf? The only reason that the really historic kernel archives still exist is that people saved them, and even so we're missing versions 0.02 and 0.03, but by the latter half of -92 there were already CD-ROMs being manufactured...
Of course, maybe the CD's are unreadable by now.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Linus Torvalds
Does anybody have old CD-ROM's lying around?
In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently released just a few months later. It would quite possibly contain the libc-2.2.2 sources... Adam Richter is still active, and I added him to the cc..
Who else was doing CD's back then? SLS? If nobody has the thing on a
There are some old SLS versions lying around here:
http://grumbeer.dyndns.org/ftp/linux/dist/SLS/
and other places but they are all binary from what i can tell. Anybody have any idea where a source tree for SLS might be? I'm finding it very hard to track down this stuff (before my time). Were there any distros that included source by default or were free that we could look to? Anyone? Put on the way-back caps.
-sb
Quoted 15 lines
web-site any more, maybe they exist in physical format on somebodys bookshelf? The only reason that the really historic kernel archives still exist is that people saved them, and even so we're missing versions 0.02 and 0.03, but by the latter half of -92 there were already CD-ROMs being manufactured...
Of course, maybe the CD's are unreadable by now.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · Linus Torvalds
It's almost certainly the "libc-2.2.2.tar.Z" file that we want
I just uploaded a copy to ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz
Andries
Linux archaeologist
Quoted 7 lines · Andries Brouwer
Quoted 1 line · Linus Torvalds
It's almost certainly the "libc-2.2.2.tar.Z" file that we want
I just uploaded a copy to ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz
Excellent same file. Where'd you come across it? And do you have any other 2.x libc lying around? Looks like the collection on your site has a couple I'm missing from 4.x series. I have an old FTP archive on my machine from back a ways, but its missing 4.2 4.1 and earlier libc
versions, do you have them anywhere as Or better yet, the filenames of
the archives they might be in, as I might already have them and just don't know it ;-)
-sb
Quoted 8 lines
Andries
Linux archaeologist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Andries Brouwer
I just uploaded a copy to ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz
OK, so that takes us back to errlist.c modified 18-Jun-92:
% tar tvfz libc-222.taz | grep errlist
-rw-r--r-- hlu/other 5601 1992-06-18 21:58:54 ./libc-linux/string/errlist.c
And yes it includes the incorrect comment.
-Mitch
Quoted 6 lines · Andries Brouwer
Quoted 1 line · Linus Torvalds
It's almost certainly the "libc-2.2.2.tar.Z" file that we want
I just uploaded a copy to ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz
Yup, and I can confirm two things:
- the strings match 100% (well, duh, we already saw that from the binary)
- it doesn't even have an "errno.h"
that, together with the timing, pretty much proves that the kernel header was indeed just auto-generated from sys_errlist[] of that timeframe, with a program very much like the one I already posted.
Now, the libc file just says
/* This is a list of all known signal numbers. */
(which is obviously just a cut-and-paste from siglist.c n the same directory). But it shouldn't much matter, since I don't think SCO really is going to try to claim copyright ownership of the result of standard C library interactions like using "sys_errlist[]".
(I take that back - _of_course_ they are going to try to claim ownership. After all, they already claimed ownership of code I provably wrote).
Linus
You should however realize that SCO has succeeded in diverting a large amount of attention from the further development of Linux to their pointless claims. Although I have to admit that I do myself find their statements quite amusing we should watch out to avoid spending too much time with their claims.
If there is a conspiracy going on against Linux they have not only found a major weakness in the development process but also a company and unwary investors to exploit it. While their claims would only affect some rather unimportant people (CEO, legal department) in a traditional company they have succeeded to distract many of the core developers from their usual focus.
Just my .02c - comments welcome!
Regards
Tom
Signature · 5 lines
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
mail [email protected]
UNIX is user-friendly ... it's just selective about who it's friends areQuoted 6 lines · Thomas Zehetbauer
You should however realize that SCO has succeeded in diverting a large amount of attention from the further development of Linux to their pointless claims. Although I have to admit that I do myself find their statements quite amusing we should watch out to avoid spending too much time with their claims.
Well maybe, but people like me who aren't actual kernel developers are doing our part to help track this stuff down. Groklaw is helping, basically the entire community is contributing. We as a community only know so much however, we can find files but only the original developers know who did what really.
Quoted 7 lines
If there is a conspiracy going on against Linux they have not only found a major weakness in the development process but also a company and unwary investors to exploit it. While their claims would only affect some rather unimportant people (CEO, legal department) in a traditional company they have succeeded to distract many of the core developers from their usual focus.
Yes they can try to exploit end users the same way they have exploited the press, the only problem is its not working. Linux users know this is total BS, but the press our the ones who spread SCO's lies. SCO knows the trial isn't for over a year and so they are using the press to wage their war. The success of Linux isn't in the press, it's in the code, and that isn't lost on anyone I don't think. Cheer up, 2.6 was just released, I don't think anything has slowed down, except this list is a little bit quiet due to the holidays, but thats nothing new :)
Merry Christmas!
sb
Quoted 4 lines
Just my .02c - comments welcome!
Regards
Tom
checked libc4 a.out and libc5, it seems it does not come from them....
Luigi
Quoted 156 lines · Giacomo A. Catenazzi
Date: Tue, 23 Dec 2003 16:44:39 +0100
From: Giacomo A. Catenazzi <[email protected]>
To: Linus Torvalds <[email protected]>
Cc: Giacomo A. Catenazzi <[email protected]>, Florian Weimer <[email protected]>,
jw schultz <[email protected]>,
"[email protected]" <[email protected]>, Eric S. Raymond <[email protected]>
Subject: Re: SCO's infringing files listQuoted 21 lines · Linus Torvalds
Quoted 10 lines · Giacomo A. Catenazzi
In
http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c/* Extended support for using errno values.
Written by Fred Fish. [email protected]
This file is in the public domain. --Per Bothner. */
(...)
#if defined (ENOTTY)
ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
#endifSomething like that may well be the source of the string. Fred Fish was active long before this timeframe (if it's the same Fred Fish - he used to do freeware collections for the Amiga in the '80's).
But there were multiple libc's around (estdio, libc5, glibc..), and it could be any of them.
Quoted 7 lines
Trying to find the kernel list archives from that timeframe would likely clarify the issue. There were several lists back then: "linux-activists" mailing list, and of course the "comp.os.linux" newsgroup (this was before it split into multiple newsgroups).
I've found some archives for linux-activists, but no newsgroup archives going that far back.. Anybody?
I found only a mail in linux-activists: It say """
4. lots of stuffs added toerrno.handstring/errlist.c.
"""
It seems that the newerrno.his added in libc, but there are some references of kernel and the post date is in the same weeks of the new kernelerrno.h, so possibly the linuxerrno.his based uppon this library. Maybe someone of the "old" guys will understand something better about this post.ciao
giacomoFrom: [email protected] (H.J. Lu)
Subject: Re: gcc-2.2.2 patches for linux?
Date: 19 Jul 92 15:42:48 GMTIn article <[email protected]> [email protected] (Clarence Wilkers
Quoted 3 lines · on)
I'd like to do cross compilation for linux on a sparc. Has anyone set this up?
--Please read all the previous release notes and docs. This release note only covers the new stuffs.
This is gcc 2.2.2 for Linux. It is on banjo.concert.net under /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS. The FSF has all the files Linux needs.
Please get the new binutils.tar.Z, which fixed some bugs in as and a gprof with some patches from Rick Sladkey at [email protected], if you haven't got it.
I added some jumptable stubs to gcc. But I don't have the time to implement it. In the future, you can use jump table with -jump in CFLAGS.
Libg++.a is 2.2 beta.
This gcc will produce binaries only run safely under 0.96a patch level 4 or above.
The list of known bugs.
1. one 'cmp' in dbz test fails. Per is not planning on doing anything about it. your contribution is welcome.
The following bugs in libc.a are fixed.
1. hard and soft math libs are fixed. some of functions are totally rewritten.
2. acosh, asinh and atanh are added to libsoft.a andmath.h.
3. open a file for read and write, then do fseek followed by fwrite works now.
4. now random () and srandom () are renamed to__random() and__srandom(), respectively.
5. the header files taken from glibc.a are fixed.
6. the sys call mount now takes 4 args.
7. getpagesize and getdtablesize work now.
8.netdb.h,resolv.h,sys/uio.h,netinet.h,arpa/inet.handarpa/nameser.hare changed.
9. Some function declarations are added tosys/socket.hin0.96bp2inc.tar.Z.The following functions are added to libc.a.
1. profil.
2. libg.a is there.
3. getdtablesize.
4. lots of stuffs added toerrno.handstring/errlist.c.
5. some changes instring/siglist.c.
6. dtoa.
7. there is a new strtod, please check it out.
8. drem.
9. the inet library functions are in libinet.a. They are untested. Once they are tested ok, they will be moved to libc.a. All the inet library functions are there, except forres_xxxx, rcmd, rexec and ruserpass, which require more kernel support, likeF_SETOWN, FASYNC, and a few network system calls.There should also be a set of files in /etc for inet functions. I hope Ross will provide them.
In this release, there is a libc_p.a compiled with "-pg" for profiling.
You should use "-g" for debugging and "-pg/-p" for profiling in CFLAGS when you compile the source code.
There must be a few other bugs. Please let me know if you find any.
File list:
1. 2.2.2db.tar.Z (cpp, libg.a and libc_p.a)
2. 2.2.2lib.tar.Z (cc1, cc1plus)
3. 2.2.2misc.tar.Z (header files, drivers, libs, doc, ....)
4. shlib-2.2.2.tar.Z (making the shared libs for gcc 2.2.2)
5. libc-2.2.2.tar.Z (source code for the libs)
6. gcc-2.2.2.tar.Z (patches for compiling gcc 2.2.2)
7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)H.J.
[email protected]
06/27/92-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Linus Torvalds
The errno change was apparently done on or around July 25, 1992. That's the date on the "
errno.h" file in the linux-0.97 archive, and it is consistent with the above release dates.If anybody has newgroup/mailing list archives from around that time, it would be very nice to see what that finds..
Well, from the linux-activists messages for that period would be in:
Specifically, the files "digest51[789] digest52[012]" are the neighborhood around july 25th. I did a quick grep for "errno" and a few strings from the errno.h file and didn't see anything relevant pop up, though.
-Mitch
Quoted 11 lines · Linus Torvalds
The errno change was apparently done on or around July 25, 1992. That's the date on the "
errno.h" file in the linux-0.97 archive, and it is consistent with the above release dates.If anybody has newgroup/mailing list archives from around that time, it would be very nice to see what that finds..
Btw: there is some incidental "evidence" that that original 0.97 version of <
linux/errno.h> is automatically generated: the thing looks to have very regular whitespace. It looks like it was generated with
Quoted 6 lines
#define\t%s\t\t%2d\t/* %s */and then tab-corrected for the symbolic name lengths.
I've found some archives for linux-activists, but no newsgroup archives going that far back.. Anybody?
Probably we have the same archives. I see the announcement
From: [email protected] (H.J. Lu)
Subject: Re: gcc-2.2.2 patches for linux?
Date: 19 Jul 1992 15:42:48 GMT
This is gcc 2.2.2 for Linux. It is on banjo.concert.net under /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS.
...
The following functions are added to libc.a.
...
4. lots of stuffs added to errno.h and string/errlist.c.
Andries
Quoted 1 line · Tom Felker
Where did the 0.97 to present version come from?
For errno.h, according to this:
http://www.geocrawler.com/archives/3/360/1997/11/0/1999771/ I got Linus to add ENOMEDIUM and EMEDIUMTYPE into the kernel for 2.0.32, as part of my work on (what was to become) the Uniform cdrom driver, based on original work from David van Leeuwen. http://www.ussg.iu.edu/hypermail/linux/kernel/9704.0/0105.html
I then helped push these defines into glibc and libc5.
So at least those two defines are clearly not SCO derived...
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
One thing I noticed.
I'm looking at include/signal.h from linux-0.01 and the definition of the signal() function, the prototype in include/signal.h is
void (*signal(int _sig, void (*_func)(int)))(int);
I then take a look in my copy of UNIX Network Programming by W. Richard Stevens from 1990, and notice that he on page 46 says this :
"...
A process specifies how it wants a signal handled by calling the signal system call.
#include <signal.h>
int (*signal (int sig, void (*func)(int)))(int);
..."
The return type here is "int" while Linus originally made the return type "void". If Linus had copied signal.h from UNIX the return type would have been "int"...
Hi Jesper,
Em Seg, 2003-12-22 às 21:01, Jesper Juhl escreveu:
Quoted 16 lines
One thing I noticed.
I'm looking at
include/signal.hfrom linux-0.01 and the definition of thesignal()function, the prototype ininclude/signal.hisvoid (*signal(int
_sig, void (*_func)(int)))(int);I then take a look in my copy of UNIX Network Programming by W. Richard Stevens from 1990, and notice that he on page 46 says this :
"...
A process specifies how it wants a signal handled by calling the signal system call.#include <
signal.h>
Quoted 8 lines
int (*signal (int sig, void (*func)(int)))(int);
..."
The return type here is "int" while Linus originally made the return type "void". If Linus had copied
signal.hfrom UNIX the return type would have been "int"...
Seems to me the Linus version comes from Minix. Its return type is
void too:
http://www.minix-vmd.org/source/std/1.5/include/signal.h
Signature · 3 lines
Luiz Fernando N. Capitulino <[email protected]> <http://www.telecentros.sp.gov.br>
These files seem to mostly include information from standards documents and
most likely contain insufficient original creative content to justify copyright protection. The particular order in which one lists the defines or the numbers one assigns to them don't seem to be protectable to me, there's no expression in them.
I had a similar issue in a code review. In this case, the relevant RFC
actually named the constants and gave their numerical values. The numerical values are used in the protocol and it's logical for multiple independent groups to both choose to use the same names used in the RFC. So our code had one header file -- a list of '#define's with the same names and numbers as someone else's code (and the same as the RFC, of course). And guess what, we both put them in numerical order too!
Not bothering to look at the RFC, the code reviewer concluded that the
identical symbol names must have meant one of us took code from the other. Duh.
DS