bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updating FreeBSD port


From: Eric Blake
Subject: Re: Updating FreeBSD port
Date: Thu, 21 Sep 2006 22:14:43 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Mikhail Teterin on 9/21/2006 10:02 PM:
> On Thursday 21 September 2006 23:54, Eric Blake wrote:
> = No, it is FreeBSD that is broken.  If you use getopt_long to implement the
> = POSIX requirements of "pr -s _", the GNU version complies whether or not
> = POSIXLY_CORRECT is set (POSIX requires it to interpret -s with no [...]
> 
> Where did pr enter the picture? We are talking about gm4 here...

pr is a POSIX utility that has an option that takes an optional argument
(most POSIX-specified utilities do not fit this bill, since POSIX has
moved away from optional arguments in general).  The point I am trying to
make is that since 'm4 -d' is an example of an optional argument, it
should behave exactly as POSIX requires that 'pr -s' should behave, and
POSIX is clear that 'pr -s _' is an option without argument followed by a
filename, although FreeBSD's getopt_long under POSIXLY_CORRECT mistakenly
treats it as an option with argument and no filename.

> 
> = > Do I have you converted yet?
> = 
> = Nope.  All you have managed to do is convince me that GNU m4 and gnulib
> = should continue rejecting the current FreeBSD getopt_long implementation
> = as broken.
> 
> So, respecting the POSIXLY_CORRECT makes something broken, while ignoring it 
> makes it correct?

Unfortunately for FreeBSD's getopt_long, yes.  That's why gnulib doesn't
use FreeBSD's implementation.

> 
> Where is the standard for getopt_long documented, anyway?

My understanding is that it was invented by GNU, then copied by BSD.  I'm
not sure if LSB or SUSv3 documents it (POSIX certainly does not).  But you
could always look to the source code in glibc, where the comments are a
pretty good documentation.  The crux of the matter is GNU's definition of
an optional argument - an option that takes an optional argument NEVER
looks beyond the current optind for that argument; if you plan on passing
an optional argument, it must not be separated by any spaces.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFE2Mz84KuGfSFAYARAjPbAKCJLe8STmdrKGHmfZW+1vEy7K+bBACggmAa
EIlJglUXzw4yPr4V+OAF3EA=
=9uS7
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]