Re: [bug-gnulib] Re: getopt and Solaris 10
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
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
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
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
-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
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
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
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
-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
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
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
-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
-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
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
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
-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
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
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
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] Re: getopt and Solaris 10
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
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
Re: getopt and Solaris 10
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
-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
