п'ятниця 22 вересень 2006 14:11, Eric Blake написав:
> Is there a link to an online CVS repository with this change?
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/getopt_long.c
> If the FreeBSD getopt_long v1.13 file behaves like GNU's getopt in all
> aspects (including the re
п'ятниця 22 вересень 2006 13:04, Andrey Chernov написав:
> On Fri, Sep 22, 2006 at 01:22:42AM -0400, Mikhail Teterin wrote:
> > The GNULIB folks are calling BSD's getopt_long implementation "broken",
> > because -- unlike theirs -- it respects the POSIXLY_COR
On Friday 22 September 2006 00:14, Eric Blake wrote:
= > 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
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 ente
четвер 21 вересень 2006 15:14, Eric Blake написав:
> > This program is calling getopt(), not the getopt_long(), that gm4 uses.
> > Is there a similar difference between GNU and BSD getopt_long()
> > implementations?
>
> It shouldn't be too hard to modify the example to find out for sure...
Could y
середа 20 вересень 2006 21:24, Eric Blake написав:
> Yes. This program demonstrates why the m4 testsuite fails when compiled
> with a BSD-flavored getopt_long:
You mean, `gmake check'? That did not fail here, when I built it with the
BSD's getopt_long...
> #include
> #include "getopt.h"
>
> in
On Thursday 21 September 2006 09:36, Eric Blake wrote:
= > Finally, does m4 actually use/document the short-options usage, that's
= > affected by the POSIX vs. GNU differences in getopt()?
=
= Yes, the info documentation for m4's -d discusses the ramifications of its
= argument being optional (and
On Thursday 21 September 2006 08:51, Eric Blake wrote:
= Sorry, but GNU coding standards require that GNU programs use long
= options, and that is already something that POSIX-specified getopt()
= cannot do.
That's alright -- the BSD getopt_long implementation can.
= Instead, gnulib makes it very
On Thursday 21 September 2006 08:33, Eric Blake wrote:
= > getopt(c, v, "r::");
=
= ...even though the "::" in this line is what makes this test program leave
= the realm of POSIX-specified behavior (and why GNU and BSD differ on
= opinion on what should happen).
It would seem to me, that it is
середа 20 вересень 2006 17:12, Paul Eggert написав:
> Mikhail Teterin <[EMAIL PROTECTED]> writes:
> > However, there is not a single place anywhere in m4's code (outside of
> > getopt*.c), where optind is set to zero.
>
> Other gnulib-using programs do rely on tha
середа 20 вересень 2006 13:24, Paul Eggert написав:
> Mikhail Teterin <[EMAIL PROTECTED]> writes:
> > I see -- would you have a test-case, that detects this difference?
>
> No, but you can read the thread containing this message:
>
> http://lists.gnu.org/archive/html/
On Wednesday 20 September 2006 09:28, Eric Blake wrote:
= > . Although FreeBSD's getopt.h is detected as sufficiently capable
= > by configure, the getopt.c and getopt1.c are still compiled and
= > linked into m4, instead of relying on the libc's versions
=
= No, the FreeBSD's geto
12 matches
Mail list logo
