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 that functionality, though, so we test for it in gnulib. It's not worth the configuration hassle to make the test depend on whether the GNU program actually needs the functionality. There are lots of fiddly bits of functionality in gnulib and we don't have time to maintain configure-time options for them all. It's simpler just to have ./configure ask "is libc compatible with our replacement?" and to use the replacement if the answer is "no". > My objection is to the code duplication. I doubt, gm4 is compiled > with its own regex on Linux No, sorry, you're mistaken on that point. gm4 currently is compiled with its own regex on GNU/Linux, and this will be true until glibc is fixed. > whatever problems/quirks there exist with GNU > regex, they (along with the fixes) should be the same for all > applications... Absolutely, and that's the long-term solution. But the situation right now is as I described. > Does running `gmake check' after building gm4 and getting all tests to > succeed, constitute a comprehensive test? Are all aspects of m4 being > covered? No, the tests are incomplete. > It is the GNU > people, who chose a name for their then-new library to clash with an earlier > one, with which they are NOT compatible. That incompatibility is fixed in gnulib regex. It's one of the bug fixes that hasn't migrated into glibc, but we plan for it to do so eventually. This should address your objection about naming conventions, and should make it possible for BSD to support the GNU features as extensions. The basic idea is that if BSD libc supports the gnulib regex interface and pass the tests in m4/regex.m4, GNU programs will run lean and mean on BSD hosts.
