Re: Updating FreeBSD port

[Eric Blake]

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

According to Mikhail Teterin on 9/21/2006 11:12 PM:
> = 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.
> 
> What evidence do you have for this? In fact, you are wrong. BSD's pr takes 
> special precautions -- to be POSIX compliant. `pr -s' works as prescribed.

If 'pr -s' works correctly on FreeBSD, it is because it took special
precautions, and does NOT use BSD's getopt_long.  You have confirmed my
argument - if 'm4- d' is to have the same semantics of optional arguments,
then it must not use FreeBSD's getopt_long.

> 
> There is, however, no POSIX requirement for `m4 -d' -- its reliance on an 
> optional argument is thus gratuitous.

Exactly - which is why GNU M4 can prescribe its semantics as a pure
extension to POSIX; and we have chosen that in GNU m4, -d takes an
optional argument.  This is perfectly compliant with POSIX, and GNU 'm4
- -d' predates the move of POSIX away from optional arguments.

> Although there is no documentation for getopt_long, you find it possible to 
> call the BSD's implementation of it broken because it respects a commonly 
> used environment variable POSIXLY_CORRECT.
> 
> The getopt manual page on my RedHat installation documents the "dual colon" 
> feature as a GNU extension. It is quite natural, that it would be turned off, 
> when POSIXLY_CORRECT is found in the environment.

On GNU systems, POSIXLY_CORRECT does not imply disabling ALL extensions,
it only implies disabling default behavior where the default is
non-compliant.  m4 -d is not specified by POSIX, therefore,
POSIXLY_CORRECT has no business changing the behavior of m4 -d, because it
is a pure extension rather than a non-compliant default.  Likewise to the
GNU :: parsing in getopt - POSIX does not specify it, so POSIXLY_CORRECT
has no business changing the behavior of getopt/getopt_long with regards
to handling short options called out with ::.  POSIXLY_CORRECT does,
however, have the right to change whether getopt is permitted to rearrange
arguments, since POSIX is explicit that filenames are not to be intermixed
with options, but GNU by default allows out-of-order parsing as an
ease-of-use non-compliant extension.

My goal with m4, along with Paul's goal for GNU coreutils, is that
POSIXLY_CORRECT should affect as little behavior as possible, because it
is just that much more of a testing and maintenance nightmare.

It seems apparent that you don't agree with my line of reasoning any more
than I agree with yours, so I probably will not be answering any more
questions in this thread.  I would love to use FreeBSD's getopt_long to
minimize the size of m4, but cannot do so unless FreeBSD's getopt_long
will not change the behavior of m4 from what it currently is.  We'll just
have to agree to disagree on whether GNU's behavior for optional arguments
to options should be consistent whether or not POSIXLY_CORRECT is in effect.

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

iD8DBQFFFAKn84KuGfSFAYARAqWRAJ98WCojhqNxidO29WaWiNQ2nAaw7ACbBpVO
STN67W3WLrnzRKieiIN/sDM=
=/6dI
-----END PGP SIGNATURE-----