bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updating FreeBSD port


From: Eric Blake
Subject: Re: Updating FreeBSD port
Date: Wed, 20 Sep 2006 07:28:17 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

According to Mikhail Teterin on 9/20/2006 7:06 AM:
> Hello!
> 
> In preparing an update of the FreeBSD port of m4 (currently at the 1.4.4) to 
> 1.4.6, I noticed the following minor nits:
> 
>       . 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 getopt is NOT sufficiently capable.  It has subtly
different semantics than GNU which break the option parsing done by m4.
Cygwin is another platform that has the BSD-flavored getopt_long but must
use gnulib's getopt for the testsuite to pass.  Read the comments in
getopt.m4.

> 
>       . FreeBSD's -lgnuregex is ignored, requiring an explicit
>         `--without-included-regex' and minor patching to src/Makefile.in
>         to add -lgnuregex to LIBS

That would also be a gnulib issue; but there I am not sure of the details
of -lgnuregex to know if it is up-to-date enough (even glibc's regex
functions have bugs that only gnulib has fixed).

> 
>       . mkstemp_safer appears to be redundant -- how can mkstemp possibly
>         return the STDIN_FILENO?

When you invoke "m4 file <&-".  Trust me, I tested it, which is why I had
to use mkstemp_safer from gnulib.

> 
>       . Although *snprintf code is compiled and linked into libm4, none of
>         these functions make it into the m4 executable -- are the files
>         obsolete?

I'll take a look at that.  It may be that it was only used by the code
that I deleted when chopping out the usage of ecvt from the implementation
of the format builtin.

> 
>       . The comment in strcase.m4 states, that no existing system provides
>         multi-byte correct strcasecmp -- is there a test one can run to check
>         a particular system? If I were to patch m4 to use the libc's 
> strcasecmp,
>         would running `gmake check' detect a problem, if there were one?

Asking the gnulib list will give you more details.  In m4 1.4.x's case,
since it is already not locale-aware, we could probably get away with
gnulib's c-strcase module, or use the platform strcasecmp.  But that is
just a bandage, since the eventual m4 2.0 is moving towards locale awareness.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFEUHx84KuGfSFAYARAno0AJ4mw7Z28odzVKczAr+QN18r8cJGmACfTOkm
zquMp5o4GYsL1IhehlSIrtE=
=TbIV
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]