l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Apr 01 10:23

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
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...

On Mon, 2002-04-01 at 00:56, msimons@moria.simons-clan.com wrote:
>   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':
> glibc-2.2.5/posix/getopt.c
> #    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.

At the time that this topic came up previously, in which we decided the
license was debatable, I don't believe glibc's getopt.c nor getopt.h had
this text.  I just examined my system, and it matches your text.  So
that presents an easy enough solution :)

libiberty's getopt.c (from, say, gcc-3.0.3) still has the GPL text.


>   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 ;)

Absolutely.  In fact, this is how the language lawyers on comp.lang.c,
and the standard's developers in comp.std.c view this.  The fact that
this is a common extension does not mean that it won't cause a valid ISO
C program to break.  Because that version of main() doesn't match the
allowed forms by the standard, it requires a diagnostic message in
conforming implementations, and if the program compiles, the behavior is

Note: since you're reading from the C9x draft... C99 adds extra verbage
allowing arbitrary "implementation-defined" versions of main();
basically, the impact is that a conformant compiler is now allowed to
accept those without a warning, and the behavior is no longer undefined
(its implementation-defined).  However, there is only one C99-conforming
compiler in existance at the moment, and chances are very good you're
not using it (it's not gcc - gcc still seems to be depressingly distant
from a conformant C99 implementation).



vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.