Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-11 Thread Karl Berry
GNU getopt tries to do too much when it reorders the commandline and
therefor needs the + as a workaround.

I don't suppose it matters at this point, but I fail to see the
connection here.  You can tell GNU getopt to REQUIRE_ORDER instead of
PERMUTE without using +, either directly or setting POSIXLY_CORRECT in
various ways.  See the __ordering enum in getopt_int.h, for example.
(Seems like you probably already know this, so maybe it's unsuitable
somehow, if so, sorry for the noise.)

Also, I don't agree that it is doing too much to have PERMUTE be the
default for GNU.  It is very useful for most programs.  cvs has
exceptional command-line parsing needs.

Happy hacking,
karl


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Matthias Kurz
On Tue, May 10, 2005, Matthias Kurz wrote:

 On Mon, May 09, 2005, Paul Eggert wrote:
 
[...]
  But I still don't get why the change is needed.  It sounds like you're
  assuming Solaris 11 getopt might get fixed?  But even in that case,
  the current code will work, right, since it will use GNU getopt?  So
  this is just an optimization for the hypothetical case if Solaris 11
  getopt gets fixed?  In that case perhaps we should wait for Solaris 11
  and test it before installing this patch, as it's more likely to cause
  a bug than to fix one.
 
 Well, it might still fail on other OSes, that also do not use GNU getopt.
 They do probably also not have the getopt_clip. I'll check this on IRIX,
 today.

The vanilla cvs-1.12.12 builds on irix and seems to run. The included
GNU getopt is used. There is a getopt.h, but no getopt_long_only. Thought,
Derek's test for -+ would be necessary, but that's not the case. I do not
have autoconf and automake, there, so i cannot test the various patches. 
I'm running out of time. I have to quit. Thanks very much for your effords.
When there is something to test, i'll still try to help.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
   Im prämotorischen Cortex kann jeder ein Held sein. (bdw) 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:


  

+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;



This doesn't null-terminate myargv.

But I still don't get why the change is needed.  It sounds like you're
assuming Solaris 11 getopt might get fixed?  


Yes, I suppose so, or a later patch release of Solaris 10.  Or some
other system that decides to ship a getopt.h with a getopt_long(),
getopt_clip(), and a GNU compatible getopt(), however unlikely that may
sound now.

But even in that case,
the current code will work, right, since it will use GNU getopt?  So
this is just an optimization for the hypothetical case if Solaris 11
getopt gets fixed?  


Basically.  I was feeling guilty about not detecting the bug, but
detecting a feature of the system and assuming the bug.  This goes
against the whole Autoconf test design philosophy, I thought.  It's
almost as bad as using `uname -a |sed' to detect the version number and
using that to decide against the system getopt(), really.

The new test detects the actual bug.

In that case perhaps we should wait for Solaris 11
and test it before installing this patch, as it's more likely to cause
a bug than to fix one.
  


What sort of bug are you worried about?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:


  

+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;



This doesn't null-terminate myargv.
  


Okay, looking at that in C89 now, but just out of curiosity, if argv
needs to be NULL terminated, what's the point of argc?

Revised patch attached.  I restored a comment I probably shouldn't have
cut as well.

2005-05-10  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.


Regards,

Derek
Index: m4/getopt.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v
retrieving revision 1.9
diff -u -p -r1.9 getopt.m4
--- m4/getopt.m46 May 2005 01:04:20 -   1.9
+++ m4/getopt.m410 May 2005 13:56:05 -
@@ -39,8 +39,26 @@ AC_DEFUN([gl_GETOPT],
 dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
 dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],[
+ char *myargv[[3]];
+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;
+ myargv[[2]] = NULL;
+ return '?' != getopt (2, myargv, +a);
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include getopt.h])])])
+  if test $gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

I'm running out of time. I have to quit. Thanks very much for your effords.
When there is something to test, i'll still try to help.


No problem.  Thanks for your help, Matthias.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgL7qLD1OTBfyMaQRAgNTAJ4yFV0txiOeuKI9/459BArLy7iVSACfYZhj
oP6Fu8IWbqICpJRFhSP376o=
=LDtS
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Larry Jones
Derek Price writes:
 
 Okay, looking at that in C89 now, but just out of curiosity, if argv
 needs to be NULL terminated, what's the point of argc?

I believe it was added for convenience back in the dark ages.  All the
Unix exec functions require a null-terminated argument list (and don't
have an explicit argument count), so argv has naturally always been null
terminated.  (And the C Standard codified that behavior: at program
startup, argv[argc] is required to be null.)

-Larry Jones

I don't think that question was very hypothetical at all. -- Calvin


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes:

 Revised patch attached.

Thanks; I installed the following slightly-different patch.

2005-05-10  Derek Price  [EMAIL PROTECTED]

* getopt.m4 (gl_GETOPT): Check for Solaris 10 bug, not decl, when
possible.

--- getopt.m4   6 May 2005 01:04:20 -   1.9
+++ getopt.m4   10 May 2005 19:11:00 -  1.10
@@ -1,4 +1,4 @@
-# getopt.m4 serial 8
+# getopt.m4 serial 9
 dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -39,8 +39,27 @@ AC_DEFUN([gl_GETOPT],
 dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
 dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], 
[gl_cv_func_gnu_getopt],
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],
+  [[
+char *myargv[3];
+myargv[0] = conftest;
+myargv[1] = -+;
+myargv[2] = 0;
+return getopt (2, myargv, +a) != '?';
+   ]])],
+[gl_cv_func_gnu_getopt=yes],
+[gl_cv_func_gnu_getopt=no],
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+  [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+  [#include getopt.h])])])
+  if test $gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

  

Revised patch attached.



Thanks; I installed the following slightly-different patch.
  



Works for me.  Thanks Paul.

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Karl Berry wrote:

 GNU getopt tries to do too much when it reorders the commandline and
 therefor needs the + as a workaround.

I don't suppose it matters at this point, but I fail to see the
connection here. You can tell GNU getopt to REQUIRE_ORDER instead of
PERMUTE without using +, either directly or setting POSIXLY_CORRECT in
various ways.


I'd rather not control a function I'm calling by messing with
environment variables, especially those that may have other side effects.

 See the __ordering enum in getopt_int.h, for example.
(Seems like you probably already know this, so maybe it's unsuitable
somehow, if so, sorry for the noise.)


It doesn't look to me like there is an easy way to set this from a
caller of getopt().

Also, I don't agree that it is doing too much to have PERMUTE be the
default for GNU. It is very useful for most programs. cvs has
exceptional command-line parsing needs.


True.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgV4aLD1OTBfyMaQRAtYPAJ9q5KLtCt4T7JwYHNWSLqgPMKe2sgCg4D9I
OIkpN56K4vKZXgSvo0tFmJM=
=iNeT
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
Matthias Kurz wrote:

On Thu, May 05, 2005, Paul Eggert wrote:

  

Derek Price [EMAIL PROTECTED] writes:



I prefer door #2.  Trivial patch attached:
  

Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
into both coreutils and gnulib.  Does it work?

2005-05-05  Paul Eggert  [EMAIL PROTECTED]

  * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
  avoid needless checks.



Yes, this also works for me.
  


Okay, one more revision, to actually check if the -+ registers as an
option or not.  This fits the autoconf paradigm of testing for the bug,
even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
later Solaris release, we shouldn't need to change anything.

When cross-compiling, I fall back on looking for the odd Solaris decl to
decide whether to use the GNULIB version of getopt or not.  If we wanted
to be really pessimistic, we could always use the GNULIB getopt when
cross-compiling, but I thought this could wait at least until we get a
report of similar behavior from some system other than Solaris 10.

Matthias, would you mind testing this version out?  If you could send me
your config.log when you are done building, that would be helpful as well.

2005-05-09  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.

Cheers,

Derek
Index: m4/getopt.m4
===
RCS file: /cvs/ccvs/m4/getopt.m4,v
retrieving revision 1.7
diff -u -p -r1.7 getopt.m4
--- m4/getopt.m46 May 2005 15:50:05 -   1.7
+++ m4/getopt.m49 May 2005 14:47:15 -
@@ -36,11 +36,26 @@ AC_DEFUN([gl_GETOPT],
   AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
 fi
 
-dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
-dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],[
+ char *myargv[[2]];
+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;
+ return '?' != getopt (2, myargv, +a);
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include getopt.h])])])
+  if test gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Matthias Kurz
On Mon, May 09, 2005, Derek Price wrote:

[...]
 Okay, one more revision, to actually check if the -+ registers as an
 option or not.  This fits the autoconf paradigm of testing for the bug,
 even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
 later Solaris release, we shouldn't need to change anything.

I do not think that this is a Solaris _bug_. GNU getopt tries to do too
much when it reorders the commandline and therefor needs the + as a
workaround. I would not hold my breath to wait for a fix from the Sun
side. But then, as long as it works for me, i'm happy with everything.

 When cross-compiling, I fall back on looking for the odd Solaris decl to
 decide whether to use the GNULIB version of getopt or not.  If we wanted
 to be really pessimistic, we could always use the GNULIB getopt when
 cross-compiling, but I thought this could wait at least until we get a
 report of similar behavior from some system other than Solaris 10.

I'd bet that every system that does not use GNU getopt will suffer from
this problem. I don't know how many of them have a getopt.h, which
triggers the problem.

 Matthias, would you mind testing this version out?  If you could send me
 your config.log when you are done building, that would be helpful as well.

Yes, i'm going to test this asap.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
   Im prämotorischen Cortex kann jeder ein Held sein. (bdw) 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

I do not think that this is a Solaris _bug_.


- From the point of view of the GNULIB getopt.m4 tests, if it doesn't
behave like GNU getopt, that is a bug.  :)

I'd bet that every system that does not use GNU getopt will suffer from
this problem. I don't know how many of them have a getopt.h, which
triggers the problem.


Well, yes, in a sense, but the tests in m4/getopt.m4 had already
eliminated all systems which don't declare a getopt_long() in favor of
the included getopt.c file from GNULIB, assuming that if getopt_long()
was declared then we could expect GNU getopt() semantics as well. 
getopt_long() is a GNU extension and not part of any standard that I
know of.

Unfortunately, in the sense that it broke the existing GNULIB getopt.m4
tests, the Solaris folks decided they liked the getopt_long() function
and imported it, without updating their getopt() to match, thereby
breaking the assumption getopt.m4 had been making thus far.

Matthias, would you mind testing this version out? If you could send me
your config.log when you are done building, that would be helpful as well.


Yes, i'm going to test this asap.


Thanks.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf49SLD1OTBfyMaQRAucQAKCZ1j8EtPQaa+1KqZSx3VGKGYvy2wCfeu4t
fgBXhyz5M7ewzUcAydnxtv0=
=oNlX
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

Hi.

One more clarification. Maybe one or the other missed my last comments
on https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. It was me,
who introduced the '+' myth.


Well, it is not a myth.  I studied the test program and output you sent
me, and Solaris does, indeed, treat the initial + as an option rather
than a request for getopt() semantics.

I analysed the problem wrong in the
beginning. It is not exactly the + that makes the problem, but the
fact, that the Solaris getopt refuses to accept a zero value on optind.
When optind==0, the Solaris getopt returns -1 immediately, leaving
optind==0. W


I did read this correctly in your report.  If anyone else sees a need
for an actual test for correct optind=0 behavior, then they are welcome
to write one, but I decided the point was moot at the moment since
detecting the + bug, just as valid as a means of selecting the GNU
getopt() over the system one, was sufficient to avoid encountering any
other bugs in the Solaris getopt().

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf5lsLD1OTBfyMaQRAiT1AJ9SOugiUFKjruvZOCi23ko9wLqGLwCg2S/R
DTImJNqzmHIonAUGmka+CNg=
=OKfo
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Matthias Kurz
On Mon, May 09, 2005, Derek Price wrote:

[...]
 I did read this correctly in your report.  If anyone else sees a need
 for an actual test for correct optind=0 behavior, then they are welcome
 to write one, but I decided the point was moot at the moment since
 detecting the + bug, just as valid as a means of selecting the GNU
 getopt() over the system one, was sufficient to avoid encountering any
 other bugs in the Solaris getopt().

I agree with you.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
   Im prämotorischen Cortex kann jeder ein Held sein. (bdw) 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
Regardless, since using an optind = 0 is not specified as supported by
POSIX, whereas optind = 1 is, and since using optind = 1 in place of
optind = 0 in CVS would avoid this problem on all platforms and with all
versions of getopt (supporting optind = 0 provides no additional
functionality that I know of), I don't think this is properly considered
a Solaris bug, but a CVS bug.

At least, it would be a CVS bug if we didn't have to use the GNU getopt
on Solaris due to the + problem anyhow.

Cheers,

Derek


Derek Price wrote:

 Matthias Kurz wrote:

 Hi.

 One more clarification. Maybe one or the other missed my last comments
 on https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. It was me,
 who introduced the '+' myth.



 Well, it is not a myth.  I studied the test program and output you sent
 me, and Solaris does, indeed, treat the initial + as an option rather
 than a request for getopt() semantics.

 I analysed the problem wrong in the
 beginning. It is not exactly the + that makes the problem, but the
 fact, that the Solaris getopt refuses to accept a zero value on optind.
 When optind==0, the Solaris getopt returns -1 immediately, leaving
 optind==0. W



 I did read this correctly in your report.  If anyone else sees a need
 for an actual test for correct optind=0 behavior, then they are welcome
 to write one, but I decided the point was moot at the moment since
 detecting the + bug, just as valid as a means of selecting the GNU
 getopt() over the system one, was sufficient to avoid encountering any
 other bugs in the Solaris getopt().

 Cheers,

 Derek


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs





___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

...I know you already agreed...  ...I just thought this was interesting...

In fact, Solaris 10 is the one actually sticking to the letter of the
POSIX spec here, not that I think that assuming argv[0] should not be
processed is going to hurt the GNU version:

The variable /optind/ is the index of the next element of the
/argv/[] vector to be processed. It is initialised to 1 by the system,

...

If, when /getopt()/ is called:

|
 /argv/[optind]is a null pointer
*/argv/[optind]is not the character -
 /argv/[optind]points to the string -
|

 /getopt/() returns -1 without changing /optind./


Cheers,

Derek


Derek Price wrote:

Regardless, since using an optind = 0 is not specified as supported by
POSIX, whereas optind = 1 is, and since using optind = 1 in place of
optind = 0 in CVS would avoid this problem on all platforms and with all
versions of getopt (supporting optind = 0 provides no additional
functionality that I know of), I don't think this is properly considered
a Solaris bug, but a CVS bug.

At least, it would be a CVS bug if we didn't have to use the GNU getopt
on Solaris due to the + problem anyhow.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf55NLD1OTBfyMaQRApD/AKDG91RXkmD1GjNyqLJmzFjQq9vCBwCfbjTw
HHeRY0WAPlT67fsFFn0PNuE=
=oFUI
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
Derek Price wrote:

2005-05-05  Paul Eggert  [EMAIL PROTECTED]

 * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
 avoid needless checks.   
  

Yes, this also works for me.



Okay, one more revision, to actually check if the -+ registers as an
option or not.  This fits the autoconf paradigm of testing for the bug,
even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
later Solaris release, we shouldn't need to change anything.

When cross-compiling, I fall back on looking for the odd Solaris decl to
decide whether to use the GNULIB version of getopt or not.  If we wanted
to be really pessimistic, we could always use the GNULIB getopt when
cross-compiling, but I thought this could wait at least until we get a
report of similar behavior from some system other than Solaris 10.

Matthias, would you mind testing this version out?  If you could send me
your config.log when you are done building, that would be helpful as well.

2005-05-09  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.
  


I've attached almost the same patch as before, except that I remembered
to put `$' in front of all my variables this time.  Matthias confirmed
that ithis new patch does the right thing on Solaris 10.

This patch is against Paul's last commit.

Cheers,

Derek
Index: m4/getopt.m4
===
RCS file: /cvs/ccvs/m4/getopt.m4,v
retrieving revision 1.7
diff -u -p -r1.7 getopt.m4
--- m4/getopt.m46 May 2005 15:50:05 -   1.7
+++ m4/getopt.m49 May 2005 20:20:00 -
@@ -36,11 +36,26 @@ AC_DEFUN([gl_GETOPT],
   AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
 fi
 
-dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
-dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],[
+ char *myargv[[2]];
+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;
+ return '?' != getopt (2, myargv, +a);
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include getopt.h])])])
+  if test $gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes:


 + myargv[[0]] = conftest;
 + myargv[[1]] = -+;

This doesn't null-terminate myargv.

But I still don't get why the change is needed.  It sounds like you're
assuming Solaris 11 getopt might get fixed?  But even in that case,
the current code will work, right, since it will use GNU getopt?  So
this is just an optimization for the hypothetical case if Solaris 11
getopt gets fixed?  In that case perhaps we should wait for Solaris 11
and test it before installing this patch, as it's more likely to cause
a bug than to fix one.


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Matthias Kurz
On Mon, May 09, 2005, Paul Eggert wrote:

 Derek Price [EMAIL PROTECTED] writes:
 
 
  + myargv[[0]] = conftest;
  + myargv[[1]] = -+;
 
 This doesn't null-terminate myargv.

D'oh !

 But I still don't get why the change is needed.  It sounds like you're
 assuming Solaris 11 getopt might get fixed?  But even in that case,
 the current code will work, right, since it will use GNU getopt?  So
 this is just an optimization for the hypothetical case if Solaris 11
 getopt gets fixed?  In that case perhaps we should wait for Solaris 11
 and test it before installing this patch, as it's more likely to cause
 a bug than to fix one.

Well, it might still fail on other OSes, that also do not use GNU getopt.
They do probably also not have the getopt_clip. I'll check this on IRIX,
today.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
   Im prämotorischen Cortex kann jeder ein Held sein. (bdw) 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] getopt and Solaris 10

2005-05-06 Thread James Youngman
On Thu, May 05, 2005 at 01:34:24PM -0400, Derek Price wrote:

 Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
 by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
 the first character of the option string.  

But surely we would now regard that usage as obsolete now?  It's been
replaced by -- hasn't it?

James.



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-06 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes:

 I prefer door #2.  Trivial patch attached:

Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
into both coreutils and gnulib.  Does it work?

2005-05-05  Paul Eggert  [EMAIL PROTECTED]

* lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
avoid needless checks.

--- getopt.m4.~1.8.~2005-01-23 00:06:57 -0800
+++ getopt.m4   2005-05-05 17:53:53 -0700
@@ -1,5 +1,5 @@
-# getopt.m4 serial 7
-dnl Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc.
+# getopt.m4 serial 8
+dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
@@ -26,11 +26,22 @@ AC_DEFUN([gl_GETOPT],
   if test -z $GETOPT_H; then
 GETOPT_H=
 AC_CHECK_HEADERS([getopt.h], [], [GETOPT_H=getopt.h])
-AC_CHECK_FUNCS([getopt_long_only], [], [GETOPT_H=getopt.h])
+if test -z $GETOPT_H; then
+  AC_CHECK_FUNCS([getopt_long_only], [], [GETOPT_H=getopt.h])
+fi
 
 dnl BSD getopt_long uses an incompatible method to reset option processing,
 dnl and (as of 2004-10-15) mishandles optional option-arguments.
-AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
+if test -z $GETOPT_H; then
+  AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
+fi
+
+dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+dnl option string (as of 2005-05-05).
+if test -z $GETOPT_H; then
+  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
+   [#include getopt.h])
+fi
 
 if test -n $GETOPT_H; then
   gl_GETOPT_SUBSTITUTE


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-06 Thread Matthias Kurz
On Thu, May 05, 2005, Paul Eggert wrote:

 Derek Price [EMAIL PROTECTED] writes:
 
  I prefer door #2.  Trivial patch attached:
 
 Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
 into both coreutils and gnulib.  Does it work?
 
 2005-05-05  Paul Eggert  [EMAIL PROTECTED]
 
   * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
   avoid needless checks.

Yes, this also works for me.

   Thanks

(mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
   Im prämotorischen Cortex kann jeder ein Held sein. (bdw) 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


getopt and Solaris 10

2005-05-05 Thread Derek Price
Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
the first character of the option string.  The original report is here:
https://ccvs.cvshome.org/issues/show_bug.cgi?id=248.

I'm assuming that GNULIB is still avoiding AC_TRY_RUN since it doesn't
work when cross-compiling?  I've asked Matthias (the bug reporter, CC'd)
if he could find some difference between Solaris 10's getopt and GNU
getopt that could be detected at compile time.  The alternative would be
always using the GNULIB getopt when installed.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] getopt and Solaris 10

2005-05-05 Thread Derek Price
James Youngman wrote:

On Thu, May 05, 2005 at 01:34:24PM -0400, Derek Price wrote:

  

Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
the first character of the option string.  



But surely we would now regard that usage as obsolete now?  It's been
replaced by -- hasn't it?
  


CVS still makes use of it bacause we can parse a line like:

   cvs -fq -d /cvsroot checkout -P -d newname module

and getopt with a + as the first character of the option string kindly
stops when it reaches the CVS command checkout.  We can then dump
everything up to optind:

argc -= optind;
argv += optind;
if (argc  1)
usage (usg);

and reuse getopt, with a new option string, to parse the arguments to
checkout.  I don't think users would appreciate having to preceded all
CVS commands with a -- argument.

   cvs -fq -d /cvsroot -- checkout -P -d newname module
   cvs -fq -d /cvsroot -- update

It's a bit redundant.

Regards,

Derek




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: getopt and Solaris 10

2005-05-05 Thread Derek Price
Derek Price wrote:

Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
the first character of the option string.  The original report is here:
https://ccvs.cvshome.org/issues/show_bug.cgi?id=248.
  


Matthias pointed me at the man page for Solaris 10's getopt_long:
http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr99?l=ena=view#indexterm-493.

Based on that man page, I see two alternatives:

1. Always use getopt_long() in CVS since the Solaris 10 version supports
+ as the start of the option string even though its getopt() does not.
2. Check for the getopt_clip() function, which should be unique to
Solaris, and use the GNULIB getopt.c when it is found.

I prefer door #2.  Trivial patch attached:

2005-05-05  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10.

Matthias, would you mind verifying that this patch fixes CVS on your
Solaris 10?

Regards,

Derek
Index: m4/getopt.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v
retrieving revision 1.8
diff -u -p -r1.8 getopt.m4
--- m4/getopt.m423 Jan 2005 08:06:57 -  1.8
+++ m4/getopt.m45 May 2005 18:51:09 -
@@ -32,6 +32,10 @@ AC_DEFUN([gl_GETOPT],
 dnl and (as of 2004-10-15) mishandles optional option-arguments.
 AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
 
+dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+dnl option string (as of 2005-05-05).
+AC_CHECK_FUNCS([getopt_clip], [GETOPT_H=getopt.h])
+
 if test -n $GETOPT_H; then
   gl_GETOPT_SUBSTITUTE
 fi
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-05 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Price wrote:

2005-05-05 Derek Price [EMAIL PROTECTED]

 * m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10.


Matthias reports that this patch does The Right Thing (tm) on Solaris
10: https://ccvs.cvshome.org/issues/show_bug.cgi?id=248.

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeoCwLD1OTBfyMaQRAhMHAJ0R2a//oSHXiFaNMjMHTbBP2nGq4gCghqjB
plPDozD5LBe5LAyjHA46zQ8=
=ChvA
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs