This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: final argp patch
Turns out there are problems leaving the argp code as is; see
following thread from gnulib. The problem is forwards-compatibility
in gnulib if the glibc argp API ever change. The conclusion, from how
I read Paul Eggert's last comment in the thread below, is that we do
one of the following options:
1 Add '#define _GNU_ARGP_INTERFACE_VERSION 1' to gnu-version.h.
Adding ELIDE_CODE checks to argp is not necessary, and as it make
the code [even] harder to read, it is probably not worth it. Adding
ELIDE_CODE would be consistent with getopt, obstack etc though.
Still, those packages can be built stand-alone, but argp currently
require gnulib helper functions to work. So it is not clear that
consistency would improve anything.
2 Remove gnu-version.h, *_INTERFACE_VERSION and remove ELIDE_CODE
hacks.
The rationale is that people should not rely on version numbers, but
instead test for functionality. I checked the glibc manual and it
doesn't discuss gnu-version.h nor *_INTERFACE_VERSION so this
wouldn't break documented behaviour. The upgrade path would be to
use gnulib, and several GNU packages already do this. The
consequences for a package that doesn't upgrade to gnulib is not
clear, but as undefined CPP symbols evaluate to zero, it appears as
if they would get a version mismatch and the application would
compile its own stuff. So it would work. I have not verified this
though.
The first change is only one line, and seem to be a conservative
choice. The second change seem to be the Right Thing, and below Paul
thought you'd might prefer that.
Do you have a preference? Are there more options?
I include the patch for 1 if you hesitate about making the larger
changes that 2 implies.
Thanks.
2003-10-03 Simon Josefsson <jas@extundo.com>
* include/gnu-versions.h (_GNU_ARGP_INTERFACE_VERSION): Add (with
value 1).
Index: gnu-versions.h
===================================================================
RCS file: /cvs/glibc/libc/include/gnu-versions.h,v
retrieving revision 1.3
diff -u -p -u -w -r1.3 gnu-versions.h
--- gnu-versions.h 6 Jul 2001 04:54:52 -0000 1.3
+++ gnu-versions.h 5 Oct 2003 22:51:41 -0000
@@ -49,5 +49,6 @@
#define _GNU_GLOB_INTERFACE_VERSION 1 /* vs posix/glob.c */
#define _GNU_GETOPT_INTERFACE_VERSION 2 /* vs posix/getopt.c and
posix/getopt1.c */
+#define _GNU_ARGP_INTERFACE_VERSION 1 /* vs argp/argp*.c */
#endif /* gnu-versions.h */
Simon Josefsson <jas@extundo.com> writes:
> Paul Eggert <eggert@CS.UCLA.EDU> writes:
>
>> Simon, this sort of Autoconf automation is already being done for
>> alloca and for fnmatch. Can you please look into doing it for argp
>> too?
>
> I had a feeling about this problem earlier, but I now realized it
> fully: the ELIDE_CODE construct is forwards-compatible, whereas
> Autoconf solution is not, as far as I understand.
>
> Specifically: If glibc argp API change in a incompatible way, with the
> ELIDE_CODE construct the gnu-version.h CPP variable is incremented.
> So an application written for the old API, and shipping a ELIDE_CODE
> argp, would detect this and use the argp that is shipped with the
> application. So it would work.
>
> But if an application is written for argp 1 and glibc is changed in an
> incompatible way, I cannot see any way the (old) argp code in gnulib
> that is shipped with an application could detect this. Instead, it
> would likely just discover that glibc do support argp, and use it.
> Which would fail since the application was written for version 1.
>
> So the ELIDE_CODE construct is not just an optimization.
>
> The option seem to be:
>
> * ignore this problem. I.e., no ELIDE_CODE and a argp.m4 in gnulib do
> AC_CHECK_FUNC(argp_parse) or something to find out if glibc support
> argp. If glibc argp API ever change, all old applications using
> argp from gnulib will no longer work.
>
> * add ELIDE_CODE.
>
> * always compile argp in gnulib, no conditional checks.
>
> Are there more options? Do you understand my concern? Any flaws in
> the above?
>
> I have only thought about this, not done any experiments, so I might
> have missed something.
>
> If my reasoning above is correct, it appears to me as if adding
> ELIDE_CODE actually is the right thing, although I also agree it is
> ugly. Perhaps modularize the ELIDE_CODE idea somewhat would make it
> less ugly.
>
> Thanks.
>
>
>
> _______________________________________________
> Bug-gnulib mailing list
> Bug-gnulib@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnulib
Paul Eggert <eggert@CS.UCLA.EDU> writes:
> Simon Josefsson <jas@extundo.com> writes:
>
>> if an application is written for argp 1 and glibc is changed in an
>> incompatible way, I cannot see any way the (old) argp code in gnulib
>> that is shipped with an application could detect this.
>
> If you want it to depend on a version number in an include file, you
> can have argp.m4 try to compile something like this program:
>
> #include <gnu-versions.h>
> #if _GNU_ARGP_INTERFACE_VERSION < 1
> #error "system argp interface is too old"
> #endif
>
> If it doesn't compile, then either the system lacks argp, or its
> interface is too old.
Simon Josefsson <jas@extundo.com> writes:
> Paul Eggert <eggert@CS.UCLA.EDU> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> if an application is written for argp 1 and glibc is changed in an
>>> incompatible way, I cannot see any way the (old) argp code in gnulib
>>> that is shipped with an application could detect this.
>>
>> If you want it to depend on a version number in an include file, you
>> can have argp.m4 try to compile something like this program:
>>
>> #include <gnu-versions.h>
>> #if _GNU_ARGP_INTERFACE_VERSION < 1
>> #error "system argp interface is too old"
>> #endif
>>
>> If it doesn't compile, then either the system lacks argp, or its
>> interface is too old.
>
> Ah, right. Except there is no _GNU_ARGP_INTERFACE_VERSION in glibc
> now. Do you think adding it to glibc, without a ELIDE_CODE patch as
> well, is the right thing? The libc manual doesn't seem to mention
> gnu-version.h nor *_INTERFACE_VERSION, so the format and use of these
> matters is probably not very fixed.
>
>
>
> _______________________________________________
> Bug-gnulib mailing list
> Bug-gnulib@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnulib
Paul Eggert <eggert@CS.UCLA.EDU> writes:
> Simon Josefsson <jas@extundo.com> writes:
>
>> > #include <gnu-versions.h>
>> > #if _GNU_ARGP_INTERFACE_VERSION < 1
>> > #error "system argp interface is too old"
>> > #endif
>> >
>> > If it doesn't compile, then either the system lacks argp, or its
>> > interface is too old.
>>
>> Ah, right. Except there is no _GNU_ARGP_INTERFACE_VERSION in glibc
>> now.
>
> In theory that's OK. A preprocessor symbol that is not defined
> evaluates to zero. So the test program won't compile, and GNU
> applications will build their own argp, and we will be no worse off
> than we already are. Once glibc has _GNU_ARGP_INTERFACE_VERSION, the
> optimizations will start to be enabled.
>
> However, I see your point. Perhaps it'd be better just to check for
> argp.h and then behave as fnmatch.m4 etc. do. This would generate
> smaller apps with the current glibc, without having to worry about
> letting _GNU_ARGP_INTERFACE_VERSION propagate to installed glibc
> versions.
>
>> Do you think adding it to glibc, without a ELIDE_CODE patch as well,
>> is the right thing?
>
> Two things:
>
> (1) It sounds like a reasonable thing to do, since it's the existing
> mechanism already used by obstack, regex, glob, and getopt.
>
> (2) However, nobody uses that mechanism as far as I know. Everybody
> uses behavior tests instead of version-number tests. This is
> because the version-number tests are less reliable.
>
> Consistency argues that either _GNU_ARGP_INTERFACE_VERSION should be
> added to gnu-versions.h, or gnu-versions.h should be removed. Most
> likely the latter would be more acceptable to the other glibc
> maintainers. I guess gnulib shouldn't care either way.