Re: [vox-tech] writing free getopt, ran into a dilemma...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] writing free getopt, ran into a dilemma...
I'm going to join the last two posts into one reply to make
On Sun, Mar 31, 2002 at 12:47:59AM -0800, Micah Cowan wrote:
> On Sat, 2002-03-30 at 04:45, firstname.lastname@example.org wrote:
> > On Thu, Mar 28, 2002 at 09:13:19AM -0800, Mark K. Kim wrote:
> > > The one I tried to link statically on Windows one time said it was GPL,
> > > but according to Micah it's apparently LGPL with misdocumentation. :P
> > readline is GPL, getopt is LGPL... maybe some maintainer got confused?
> getopt's license would seem to be debatable - the sourcefile itself
> claims to be plain ol' GPL, though the accompanying, seperate license
> file claims LGPL.
I admit I didn't check the source files the first time, because
logically it *MUST* have the LGPL if it is linked into *the* libc
that practically every binary on a Linux system uses. I'm not
much for logic proofs but I think this could be a proof by
If getopt used the GPL, then everything linked to it must also
(meaning the rest of libc), and anything linked to that (including
dynamically linked) would have to... thus every binary that runs
on a Linux system is GPL'd. Time to contact Oracle about their
Well that was fun, now back to reality. The above demonstrates
the 'viral license' concept microsoft whines about.
Since I'm generally bad at proofs a source to backup that idea
that everything linked to a GPL thing must also have a GPL license...
comes from the preamble of the LGPL where it describes the differences
between itself and the GPL.
# When a program is linked with a library, whether statically or using
# a shared library, the combination of the two is legally speaking a
# combined work, a derivative of the original library. The ordinary
# General Public License therefore permits such linking only if the
# entire combination fits its criteria of freedom. The Lesser General
# Public License permits more lax criteria for linking other code with
# the library.
So we have another reference problem... what source code tarfile
(or whatever) did you find the GPL attached to getopt.c?
I checked my copy of source which I got via "apt-get source glibc"
with timestamps shown [way] below. Both my header and source files have
references to the 'GNU Lesser General Public License':
# The GNU C Library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
Stallman playing his word games renamed the 'Library General Public
License' to the 'Lesser General Public License' I suspect in an attempt
to make it sound more distasteful... he may have had other reasons,
regardless they are both the 'LGPL' we have been talking about.
[...okay onto the second post]
On Sun, Mar 31, 2002 at 12:40:30AM -0800, Micah Cowan wrote:
> > > Intermixing options with arguments is a GNU
> > > extension, and GNU pulls some mildly dirty tricks to get it (such as
> > > permuting argv, despite the fact that it's elements are declared const).
> > Here is what I believe the valid declarations to be (these from ANSI C):
> > int main(void);
> > int main(int argc, const char **argv);
> No, the second shouldn't have the "const".
> > POSIX adds the following one additional main:
> > int main(int argc, const char **argv, const char **envp);
> This is a standard UNIX convention, but is not POSIX (at least, I can't
> find it).
Okay so I've now stumbled on a copy of the ISO draft standard,
dated about the middle of January 1999. Thanks for the link,
I'll keep that in mind if I ever need the 'real thing'.
I agree 100% const is not part of main in the standard.
However, I found that
int main(int argc, char **argv, char **envp);
is listed as a 'common extension' it appears that the ISO rule is
extensions which can not cause a valid ISO C program to break when
compiled in that environment are allowed by the standard. (In
my opinion since main with envp isn't defined by the standard the
programs that use that form of main are not ISO C programs even through
every other line may be ISO C ;)
# J.5 Common extensions
# [#1] The following extensions are widely used in many
# systems, but are not portable to all implementations. The
# inclusion of any extension that may cause a strictly
# conforming program to become invalid renders an
# implementation nonconforming. Examples of such extensions
# J.5.1 Environment arguments
# [#1] In a hosted environment, the main function receives a
# third argument, char *envp, that points to a null-
> > POSIX declares:
> > int getopt(int argc, char * const *argv, const char *optstring);
> More or less.
> > However the GNU documentation declares:
> > int getopt(int argc, char **argv, const char *optstring);
> Mine sure doesn't. Mine says "char * const *argv". So does the
> header. I have never seen a Linux system with a different declaration
> than this, so now you have my curiosity piqued, as to what system you're
I'm sorry I posted the documentation reference in another message,
here it is again...
Since the GNU people officially don't maintain manpages anymore in favor
of their "texinfo pages", I was referring that. I even went through
the "effort" of finding the URL on gnu.org's own machines and verified
the content of the small sections I cared about with the source, so that
it wouldn't be an old out of date copy I was quoting. :)
msimons@gabriel:~/src/glibc-2.2.5/manual> ls -l getopt.texi
-rw-r--r-- 1 msimons users 11892 Nov 10 09:16 getopt.texi
> The manpage is dated 8 May 1998, ships with RH 7.1; my glibc
> is currently 2.2.4. BTW, the manpage gives a reason as to why this is
> the case, I just think it's a very ugly way of doing it.
Oh yes, I run Debian and my man page is dated the same as yours.
However, we are using glibc 2.2.5. ;)
When one installs the 'glibc-doc' package one gets a bunch of html
which is based off of the texinfo pages which is deemed to be the
> > The one valid bug I see is that GNU getopt.h and getopt.c both use
> > 'char * const *argv' and that conflicts with the documentation
> > of 'char **argv'.
> But not with my documentation, obviously. So it looks like they
> originally had it your way but later changed it for compatibility with
> certain other systems (although why such compatibility is necessary with
> *BSD escapes me - compatibility with POSIX would be a good reason;
> libiberty might be another).
The modification order may very well be, although oddly the time order
of file change in the upstream source is header, source, documentation. ;)
ls -l posix/getopt.c posix/getopt.h manual/getopt.texi -tr
-rw-r--r-- 1 msimons users 6458 Sep 7 2001 posix/getopt.h
-rw-r--r-- 1 msimons users 34090 Oct 27 07:21 posix/getopt.c
-rw-r--r-- 1 msimons users 11892 Nov 10 09:16 manual/getopt.texi
vox-tech mailing list