GNU Patch 2.6.1 fails to build on Darwin
Hello, Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]: --8<---cut here---start->8--- gcc -std=gnu99 -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"/nix/store/1dk6yj85f9j1manfrd3001az2r7ggb8n-ed-1.4/bin/ed\" -DENABLE_MERGE -I. -I./src -I./gl/lib -g -O2 -o gl/lib/strndup.o gl/lib/strndup.c gl/lib/strndup.c: In function 'strndup': gl/lib/strndup.c:33: warning: implicit declaration of function 'rpl_strnlen' [...] gcc -std=gnu99 -o src/patch -g -O2 gl/lib/argmatch.o gl/lib/backupfile.o gl/lib/basename.o gl/lib/dirname.o gl/lib/stripslash.o gl/lib/error.o gl/lib/exitfail.o gl/lib/strndup.o gl/lib/strnlen.o gl/lib/getopt.o gl/lib/getopt1.o gl/lib/hash.o gl/lib/quote.o gl/lib/quotearg.o gl/lib/safe-write.o gl/lib/xmalloc.o gl/lib/xstrndup.o gl/lib/full-write.o src/merge.o src/inp.o src/maketime.o src/partime.o src/patch.o src/pch.o src/quotesys.o src/util.o src/version.o i686-apple-darwin9-gcc-4.0.1: gl/lib/strnlen.o: No such file or directory --8<---cut here---end--->8--- Thanks, Ludo’. [0] http://hydra.nixos.org/build/216441/nixlog/1/raw
Re: warn-on-use preview, v2
According to Bruno Haible on 1/9/2010 8:53 AM: > Eric Blake wrote: >> Here's spin two of the patch. > >> [PATCH 1/4] warn-on-use: new module >> ... >> + supported by the compiler. If the compiler does not support this >> + feature, the macro expands to an unused typedef declaration. > > It's now an 'extern' declaration, so I would change > "unused typedef declaration" -> "unused dummy declaration". I had noticed that as well, and had already changed it in my rebasing. > > The rest looks all right. Thanks for the review. Now applied. I'll start a new thread for the next patch in the series. -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature
[PATCH] utimecmp: avoid new warning from upcoming gcc-4.5.0
This new warning is debatable:
utimecmp.c: In function 'utimecmp':
utimecmp.c:222:36: error: comparison between 'enum ' and 'enum
' [-Wenum-compare]
The code in question:
enum { BILLION = 1000 * 1000 * 1000 };
/* Best possible resolution that utimens can set and stat can return,
due to system-call limitations. It must be a power of 10 that is
no greater than 1 billion. */
#if HAVE_UTIMENSAT
enum { SYSCALL_RESOLUTION = 1 };
#elif ((HAVE_FUTIMESAT || HAVE_WORKING_UTIMES) \
&& (defined HAVE_STRUCT_STAT_ST_ATIM_TV_NSEC \
|| defined HAVE_STRUCT_STAT_ST_ATIMESPEC_TV_NSEC \
|| defined HAVE_STRUCT_STAT_ST_ATIMENSEC \
|| defined HAVE_STRUCT_STAT_ST_ATIM_ST__TIM_TV_NSEC \
|| defined HAVE_STRUCT_STAT_ST_SPARE1))
enum { SYSCALL_RESOLUTION = 1000 };
#else
enum { SYSCALL_RESOLUTION = BILLION };
#endif
and here's line 222:
if (SYSCALL_RESOLUTION == BILLION)
In general I use "enum"s for constants like this, so that defined symbols
are accessible in the debugger, but "BILLION" is pretty obvious here,
so I prefer to compromise its definition in gnulib, rather than to
require each utimecmp-using package (with a strict, non-warning policy)
to do something like the following patch, which I wrote but am not going
to use in coreutils.
So I've pushed this.
>From 56a9c0c14e067f5375863981337056a31e45c8f0 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 11 Jan 2010 16:50:02 +0100
Subject: [PATCH] utimecmp: avoid new warning from upcoming gcc-4.5.0
* lib/utimecmp.c (BILLION): Define using #define rather than an
anonymous enum, to placate upcoming gcc-4.5.0's -Wenum-compare.
---
ChangeLog |6 ++
lib/utimecmp.c |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 291b88b..d075b31 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-01-11 Jim Meyering
+
+ utimecmp: avoid new warning from upcoming gcc-4.5.0
+ * lib/utimecmp.c (BILLION): Define using #define rather than an
+ anonymous enum, to placate upcoming gcc-4.5.0's -Wenum-compare.
+
2010-01-11 Eric Blake
math: add portability warnings for classification macros
diff --git a/lib/utimecmp.c b/lib/utimecmp.c
index 81c36b3..63a0c9a 100644
--- a/lib/utimecmp.c
+++ b/lib/utimecmp.c
@@ -39,7 +39,7 @@
# define MAX(a, b) ((a) > (b) ? (a) : (b))
#endif
-enum { BILLION = 1000 * 1000 * 1000 };
+#define BILLION (1000 * 1000 * 1000)
/* Best possible resolution that utimens can set and stat can return,
due to system-call limitations. It must be a power of 10 that is
--
1.6.6.439.gaf68f
>From 77c4d350e18e48214431f321c0d3e598bb0327af Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 11 Jan 2010 16:29:26 +0100
Subject: [PATCH] build: avoid a warning in gnulib from experimental gcc-4.5.0
* configure.ac (GNULIB_WARN_CFLAGS): Remove -Wenum-compare,
to avoid a warning that is new in 4.5.0 20100109.
---
configure.ac |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index b07a52b..4c35c02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -122,6 +122,11 @@ if test "$gl_gcc_warnings" = yes; then
nw="$nw -Wunused-macros"
nw="$nw -Wmissing-prototypes"
nw="$nw -Wold-style-definition"
+
+ # The sole violation is in utimecmp.c:222, but it doesn't seem to
+ # merit the warning or a fix.
+ gl_WARN_ADD([-Wno-enum-compare])
+
gl_MANYWARN_COMPLEMENT([GNULIB_WARN_CFLAGS], [$WARN_CFLAGS], [$nw])
AC_SUBST([GNULIB_WARN_CFLAGS])
fi
--
1.6.6.439.gaf68f
Re: warn-on-use preview, v2
Eric Blake byu.net> writes: > Here's spin two of the patch. It turns out that doing one shell loop per > header also allows us to fold in platform-specific inclusion requirements. > ... > Some of our unit tests never use large files, so rather than drag > in a dependency on fseeko, they should be the first compilation > units to use _GL_NO_LARGE_FILES. I found a couple more tests that warned, but which have no reason to warn. From: Eric Blake Date: Mon, 11 Jan 2010 10:35:52 -0700 Subject: [PATCH] tests: avoid more large file warnings * tests/test-fflush.c: Avoid warning about ftell use. * tests/test-fseek.c: Avoid warning about fseek use. Signed-off-by: Eric Blake --- ChangeLog |6 ++ tests/test-fflush.c |3 +++ tests/test-fseek.c |3 +++ 3 files changed, 12 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index d075b31..a06814b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-01-11 Eric Blake + + tests: avoid more large file warnings + * tests/test-fflush.c: Avoid warning about ftell use. + * tests/test-fseek.c: Avoid warning about fseek use. + 2010-01-11 Jim Meyering utimecmp: avoid new warning from upcoming gcc-4.5.0 diff --git a/tests/test-fflush.c b/tests/test-fflush.c index 38bedd9..12403e2 100644 --- a/tests/test-fflush.c +++ b/tests/test-fflush.c @@ -18,6 +18,9 @@ #include +/* None of the files accessed by this test are large, so disable the + ftell link warning if we are not using the gnulib ftell module. */ +#define _GL_NO_LARGE_FILES #include #include "signature.h" diff --git a/tests/test-fseek.c b/tests/test-fseek.c index 9b25e1d..46d5c8a 100644 --- a/tests/test-fseek.c +++ b/tests/test-fseek.c @@ -18,6 +18,9 @@ #include +/* None of the files accessed by this test are large, so disable the + fseek link warning if the user requested GNULIB_POSIXCHECK. */ +#define _GL_NO_LARGE_FILES #include #include "signature.h" -- 1.6.4.2
Re: I: coreutils tests/misc/nproc-avail fails on GNU/Linux without /proc and /sys mounted
Pádraig Brady wrote: > > Here's a proposed patch. > > Looks good. OK, I've applied it now. Bruno
coreutils-8.4 very soon
Hi Bruno and Eric, Considering the coreutils-8.3 build failures, I'm going to release coreutils-8.4 soon, perhaps on Wednesday. A cursory review and preliminary testing suggests that it will be safe to use the latest from gnulib. Since you two have made relatively large changes recently, what do you think of using the latest in a bug-fix-only coreutils release? I'll make a snapshot tomorrow and hope it gets wider testing this time.
Re: GNU Patch 2.6.1 fails to build on Darwin
Ludovic Courtès gnu.org> writes: > Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]: > > --8<---cut here---start->8--- > gcc -std=gnu99 -c -DHAVE_CONFIG_H > -Ded_PROGRAM=\"/nix/store/1dk6yj85f9j1manfrd3001az2r7ggb8n-ed-1.4/bin/ed\" - DENABLE_MERGE > -I. -I./src -I./gl/lib -g -O2 -o gl/lib/strndup.o gl/lib/strndup.c > gl/lib/strndup.c: In function 'strndup': > gl/lib/strndup.c:33: warning: implicit declaration of function 'rpl_strnlen' > > [0] http://hydra.nixos.org/build/216441/nixlog/1/raw I can't get it to fail for me, even when cross-compiling from cygwin to mingw. Looking at that log, I don't see where the gnulib replacement string.h was built. Are you using gnulib-tool --import, or are you pulling in modules manually? My guess is that you are doing manual importing, and that you missed the step that builds the replacement string.h header, and thus putting the bug in patch's court rather than gnulib. -- Eric Blake
Re: coreutils-8.4 very soon
Hi Jim, > Since you two have made relatively large changes recently, > what do you think of using the latest in a bug-fix-only coreutils release? The changes between commit 7a29e0093f4a87478cdf7b7c87786272d6f37dfe and today look reasonably safe. Most of new the libunistring tests won't affect coreutils. Bruno
getlogin(_r) self-test failures
These tests are fail unnecessarily easy, I think. See:
$ rm -rf m && ./gnulib-tool --create-testdir --dir m --with-tests getlogin_r &&
cd m && ./configure && nohup make check > log 2>&1
How about this patch?
/Simon
diff --git a/ChangeLog b/ChangeLog
index 3509cdd..8c726be 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-01-11 Simon Josefsson
+
+ * tests/test-getlogin.c (main): When invoked non-interactively,
+ skip test instead of failing.
+ * tests/test-getlogin_r.c (main): Likewise.
+
2010-01-10 Bruno Haible
nproc: Work better on Linux when /proc and /sys are not mounted.
diff --git a/tests/test-getlogin.c b/tests/test-getlogin.c
index 6589289..8e107f7 100644
--- a/tests/test-getlogin.c
+++ b/tests/test-getlogin.c
@@ -35,7 +35,8 @@ main (void)
/* Test value. */
buf = getlogin ();
- ASSERT (buf != NULL);
+ if (buf == NULL)
+return 77;
/* Compare against the value from the environment. */
#if !((defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__)
diff --git a/tests/test-getlogin_r.c b/tests/test-getlogin_r.c
index f566e03..6e1fe6e 100644
--- a/tests/test-getlogin_r.c
+++ b/tests/test-getlogin_r.c
@@ -34,8 +34,11 @@ main (void)
{
/* Test with a large enough buffer. */
char buf[1024];
+ int rc;
- ASSERT (getlogin_r (buf, sizeof (buf)) == 0);
+ rc = getlogin_r (buf, sizeof (buf));
+ if (rc != 0)
+return 77;
/* Compare against the value from the environment. */
#if !((defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__)
Re: another dup2 mingw failure
Eric Blake writes:
> According to Simon Josefsson on 1/9/2010 4:06 AM:
>> There is another dup2 failure due to Wine, see:
>>
>> http://bugs.winehq.org/show_bug.cgi?id=21291
>>
>> The patch below works around it. Thoughts?
>
> Hmm. Repeatedly adding workarounds for wine bugs seems awkward. If the
> goal is making wine a windows emulator, it seems like we are better off
> giving the wine project a little while to fix their bug, rather than
> making a permanent workaround in gnulib that will be obsoleted as soon as
> wine is updated. It's bad enough that mingw is already awkward enough to
> port to, without having to also deal with porting to wine bugs.
I understand this, but supporting Wine as a platform makes it easy to
check if GNU packages work under Windows easily (just build them using a
mingw cross-compiler and run self-tests under Wine).
I suspect Wine is a more common (and important) operating environment
compared to some of the more exotic systems that we support in gnulib.
Having support for it results in GNU packages working better on Windows,
and consequently more Windows people will be exposed to free software,
which seems like a good thing.
> That said, here's a review of your proposed patch:
>
>>
>> +#if !O_BINARY
>> +# define setmode(f,m) zero ()
>> +static int zero (void) { return 0; }
>> +#endif
>
> That snippet is fine for unit tests, but for actual modules, it is better
> to depend on binary-io and use the setmode declaration from "binary-io.h".
> I'm assuming that the use of zero is a spurious copy-n-paste. That, and
> since all your uses of setmode() are already guarded by _WIN32, you don't
> really need to worry about #defining setmode on platforms where O_BINARY is 0.
Right.
>> +
>> int
>> rpl_dup2 (int fd, int desired_fd)
>> {
>>int result;
>> # if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>> + int fd_mode = -1;
>>/* If fd is closed, mingw hangs on dup2 (fd, fd). If fd is open,
>> dup2 (fd, fd) returns 0, but all further attempts to use fd in
>> future dup2 calls will hang. */
>> @@ -59,6 +65,14 @@ rpl_dup2 (int fd, int desired_fd)
>>errno = EBADF;
>>return -1;
>> }
>> + /* Wine 1.0.1 puts desired_fd into binary mode when fd is in text
>> + mode, so we save the old mode here.
>> + http://bugs.winehq.org/show_bug.cgi?id=21291 */
>> + if ((HANDLE) _get_osfhandle (fd) != (HANDLE) -1)
>> +{
>> + fd_mode = setmode (fd, O_BINARY);
>> + setmode (fd, fd_mode);
>> +}
>> # endif
>>result = dup2 (fd, desired_fd);
>> # ifdef __linux__
>> @@ -80,6 +94,12 @@ rpl_dup2 (int fd, int desired_fd)
>>if (fd != desired_fd && result != -1)
>> result = _gl_register_dup (fd, result);
>> # endif
>> +# if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>
> Is there a wine-specific preprocessor witness that we can use to
> distinguish compilation for wine vs. native?
That's not possible, the same EXE file should work on both Wine and
native Windows.
>> + /* Restore text mode if needed.
>> + http://bugs.winehq.org/show_bug.cgi?id=21291 */
>> + if (result != -1 && fd_mode != -1)
>> +setmode (desired_fd, fd_mode);
>
> Yes, this looks like it would resolve the problem, logic wise. It's now
> just a question of policy, whether we want to apply it.
Right.
/Simon
Re: open MinGW failure
Bruno Haible writes:
>> The relevant code is:
>>
>> /* Cannot create directory. */
>> errno = 0;
>> ASSERT (func ("nonexist.ent/", O_CREAT | O_RDONLY, 0600) == -1);
>>
>> Open returns 3 for me, and it has created a file 'nonexist.ent'.
>
> This must be a bug in Wine, then. Please report it.
Yes, already done see my followup post and
http://bugs.winehq.org/show_bug.cgi?id=21292 in particular.
>> I see there is some code for this in lib/open.c, however it is not used
>> because:
>>
>> /* Define to 1 if open() fails to recognize a trailing slash. */
>> /* #undef OPEN_TRAILING_SLASH_BUG */
>>
>> Defining it makes the self-test work, which argues there is a bug in the
>> open.m4 detection code, indeed it is not run at all for MinGW:
>>
>> case "$host_os" in
>> mingw* | pw*)
>> gl_REPLACE_OPEN
>> ;;
>> *)
>>
>> A simple fix to the problem is attached.
>
> Hmm, you and Paolo explained to me on 2009-08-21 that Wine should be
> considered as a platform of its own. But I still don't fully agree. Can
> you first report the bug to the Wine people and come back to patching
> gnulib only if they are not fixing it within two months?
We'll see what happens. For a rationale for supporting Wine as a
separate platform, see my other post in this thread.
>> I wonder if the code is correct for the 'pw*' system though, it will not
>> trigger the trailing slash test on it. I don't know what pw* is, and
>> can't test it, so I'll leave that to others.
>
> 'pw32' is Paul Sokolovsky's "POSIX over Win32" package [1], which was
> developed in 2000-2001 and appears to be abandoned now [2].
Thanks for pointers.
/Simon
Re: open MinGW failure
Paolo Bonzini writes: > On 01/09/2010 12:33 PM, Bruno Haible wrote: >> Hmm, you and Paolo explained to me on 2009-08-21 that Wine should be >> considered as a platform of its own. But I still don't fully agree. Can >> you first report the bug to the Wine people and come back to patching >> gnulib only if they are not fixing it within two months? > > I agree with this. Alternatively we could just make sure that code > paths in configure that differ for Wine and Windows do all tests using > cache variables, so that these can be tweaked with config.site when > people use Wine. Yes, that would help (but a bit time consuming). > If we don't do that, we should anyway use no mercy for old versions > and un-patch it as soon as it is fixed in Wine. That's fine with me. The bug is present in the latest stable Wine release though. /Simon
New stable snapshot
Hi, I've released a new stable snapshot. See attached NEWS.stable for details. Feedback welcome. Tarball: http://erislabs.net/ianb/projects/gnulib/gnulib-20100109-stable.tar.gz Gitweb: http://erislabs.net/gitweb?p=gnulib.git;a=shortlog;h=refs/heads/stable Git: git://erislabs.net/gnulib.git tag: stable/20100109 (stable branch, master is the debian branch, derived from stable). Ian. -- Ian Beckwith - i...@erislabs.net - http://erislabs.net/ianb/ GPG fingerprint: AF6C C0F1 1E74 424B BCD5 4814 40EC C154 A8BA C1EA Gnulib stable snapshot -- * 20100109-stable Snapshot taken based on: commit 12319ff4e84ca616a671216d991dd6eaf1c39c47 Date: Fri Jan 1 16:00:07 2010 +0100 with the following additional commits: * [e7100ae]->[60a41fa] headers: make check of system header explicit * [1bf02c3]->[2e79dd2] wchar: Remove unused configure check. * [8f3aa1f]->[ab43907] autoupdate * [e138cd8]->[18a2e77] fdopendir: fix configure test * [7a29e00]->[11639c6] nl_langinfo: avoid configure-time syntax error * [51983dc]->[fab630e] mkdir: avoid xalloc * [28e6fc0]->[b8025c4] xalloc.h: use consistent formatting * [0c2fded]->[41d7de2] maint.mk: include 4 more function names in alloca.h-checking regexp * [0e0f8f1]->[2d44e17] maint: remove useless inclusions of "alloca.h" * [c1b6197]->[9e93370] ChangeLog: correct last entry: s/alloca.h/xalloc.h/ * [f8b8f4f]->[bfdc843] strcase: document what it provides * [41c44a6]->[88de58a] utimens (fdutimens): ignore a negative FD, per contract * [735d9d0]->[8a69e5c] maint: support 'make announcement' from a VPATH build * [816a1ec]->[0d57ec9] readtokens: this module *does* require xalloc.h * [f9eed4b]->[58b5448] nl_langinfo: do not call AC_CHECK_FUNC_ONCE inside if. * [60ad192]->[932e55d] stdio, unistd: guarantee ssize_t * [ae0044c]->[78c1179] autoupdate * [eb9c0c2]->[d0f97a4] cleanup after gl_FUNC_READLINK, for gl_FUNC_SYMLINK test * [e5697c6]->[b4e7212] linkat, renameat: avoid bad free * [010ecd2]->[65e8854] dirent: fix test failure * [978114f]->[eb65fea] pread: fix compilation on glibc * [2f0e0a8]->[c93838e] doc: regenerate INSTALL * [654c876]->[4b8c490] select: add missing dependency * [c4b4563]->[9ebfb66] maint.mk: ignore multi-line copyright in NEWS * [cb361c9]->[d9d722c] maint.mk: detect incorrect GFDL usage * [c1a179c]->[abd3f20] wctype: allow C++ use * [6751651]->[1c3411f] autoupdate * [5cd308a]->[d1ecc61] ChangeLog: Correct a recent entry. * [7f01cc5]->[77f03a3] nl_langinfo: Simplify logic. * [cc6a687]->[efba37d] doc: Clarify the platforms. * [64cbadd]->[a75ac7f] xlist, xoset: Fix missing dependency bug, introduced on 2009-12-13. * [f1195cc]->[877b01f] stdio: Ensure defines off_t, ssize_t, va_list. * [027bd46]->[53c2db0] dirent: Document the last fix. * [969fe75]->[085b493] mbslen: Avoid collision with system function. * [ccc06b2]->[3437136] Fix indentation of wctype.in.h, broken since 2007-01-06. * [0906b5f]->[6b40a56] glob: Fix C++ compilation. * [2cf2e37]->[0b0ac4a] dup2: work around mingw bug * [581419c]->[fad0fe1] lib/dup2.c (rpl_dup2): Improve comment. * [dd5823d]->[465b4d1] Tests for module 'getlogin_r'. * [3361cfa]->[5bfd3af] getlogin_r: Add comment. * [89b39ef]->[88bc1a6] getlogin_r: Small fixes. * [570a589]->[d6b7bf8] getlogin_r: Support for native Windows. * [630a387]->[b2c3f71] unistr/u8-to-u16: Reject invalid input. * [95a86a9]->[f3af270] unistr/u8-to-u32: Reject invalid input. * [f03c8d5]->[987b3c4] unistr/u16-to-u8: Reject invalid input. * [19aa55e]->[b4ee15b] unistr/u16-to-u32: Reject invalid input.
Re: coreutils-8.4 very soon
On Mon, Jan 11, 2010 at 10:25:53PM +0100, Jim Meyering wrote: > Considering the coreutils-8.3 build failures, I'm going to release > coreutils-8.4 soon, perhaps on Wednesday. A cursory review and > preliminary testing suggests that it will be safe to use the latest > from gnulib. Since you two have made relatively large changes recently, > what do you think of using the latest in a bug-fix-only coreutils release? If you are feeling daring, you might want to try my just-released stable snapshot. At Bruno's suggestion, I've been making periodic stable snapshots of gnulib (well, this is only my second). I froze on January 1st, and cherry-picked uncontroversial-looking fixes up until January 9th. Tarball: http://erislabs.net/ianb/projects/gnulib/gnulib-20100109-stable.tar.gz Gitweb: http://erislabs.net/gitweb?p=gnulib.git;a=shortlog;h=refs/heads/stable Git: git://erislabs.net/gnulib.git tag: stable/20100109 (stable branch, master is the debian branch, derived from stable). See NEWS.stable in the tarball or my just-posted announcement mail for which commits are included. Ian -- Ian Beckwith - i...@erislabs.net - http://erislabs.net/ianb/ GPG fingerprint: AF6C C0F1 1E74 424B BCD5 4814 40EC C154 A8BA C1EA
[PATCH] mbswidth: add new functions to handle tabs
Bison currently contains a wrapper around mbsnwidth to compute screen
columns while accounting for tabs. Based on Bison's ChangeLog, the
wrapper was originally written by Paul Eggert.
I'd like to use this wrapper in other projects, so I thought it would be
nice to generalize it a little and move it to gnulib. For example, if
STRING starts at COLUMN and the tab-stop interval is 8, you can compute
the column following STRING like this:
column += mbstwidth (string, column, 8, 0);
Below is a patch, not yet pushed, to implement that and a corresponding
mbstnwidth. Does this duplicate any functionality already offered in
gnulib? Is it general enough for gnulib?
I also considered providing a means to compute line numbers at the same
time. However, last time I checked, counting newlines is not sufficient
for all text file formats. To handle it generally, we might need to scan
for matches to some user-provided regular expression or set of literal
strings. For my purposes, I prefer to count lines separately and just
pass the contents of lines I find interesting to mbstwidth. Besides,
counting lines doesn't really seem to fit the concept of "width".
After applying the patch below to my local gnulib and adapting Bison to
use the new functions, Bison's test suite passes, so I feel the code is
likely correct. Nevertheless, at some point, I should add some formal
tests to gnulib.
>From da35410a0fa0fab4dca3302c035f84822b3bba43 Mon Sep 17 00:00:00 2001
From: Joel E. Denny
Date: Mon, 11 Jan 2010 20:31:44 -0500
Subject: [PATCH] mbswidth: add new functions to handle tabs
Generalized from code originally written by Paul Eggert for GNU
Bison.
* lib/mbswidth.c (add_column_width): New static inline function.
(mbstwidth): New function.
(mbstnwidth): New function.
* lib/mbswidth.h (mbstwidth, mbstnwidth): Prototype.
---
ChangeLog | 10 ++
lib/mbswidth.c | 55 +++
lib/mbswidth.h | 12
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 3509cdd..d06fa7a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2010-01-11 Joel E. Denny
+
+ mbswidth: add new functions to handle tabs
+ Generalized from code originally written by Paul Eggert for GNU
+ Bison.
+ * lib/mbswidth.c (add_column_width): New static inline function.
+ (mbstwidth): New function.
+ (mbstnwidth): New function.
+ * lib/mbswidth.h (mbstwidth, mbstnwidth): Prototype.
+
2010-01-10 Bruno Haible
nproc: Work better on Linux when /proc and /sys are not mounted.
diff --git a/lib/mbswidth.c b/lib/mbswidth.c
index caf0c4d..7ead24b 100644
--- a/lib/mbswidth.c
+++ b/lib/mbswidth.c
@@ -29,6 +29,9 @@
/* Get isprint(). */
#include
+/* Get INT_MAX. */
+#include
+
/* Get mbstate_t, mbrtowc(), mbsinit(), wcwidth(). */
#include
@@ -165,3 +168,55 @@ mbsnwidth (const char *string, size_t nbytes, int flags)
}
return width;
}
+
+/* If BUF is null, add BUFSIZE (which in this case must be less than
+ INT_MAX) to COLUMN; otherwise, add mbsnwidth (BUF, BUFSIZE, 0) to
+ COLUMN. If an overflow occurs, or might occur but is undetectable,
+ return INT_MAX. Assume COLUMN is nonnegative. */
+static inline int
+add_column_width (int column, char const *buf, size_t bufsize, int flags)
+{
+ size_t width;
+ unsigned int remaining_columns = INT_MAX - column;
+
+ if (buf)
+{
+ if (INT_MAX / 2 <= bufsize)
+return INT_MAX;
+ width = mbsnwidth (buf, bufsize, flags);
+}
+ else
+width = bufsize;
+ return width <= remaining_columns ? column + width : INT_MAX;
+}
+
+int
+mbstwidth (const char *string, int column, int tab, int flags)
+{
+ return mbstnwidth (string, strlen (string), column, tab, flags);
+}
+
+int
+mbstnwidth (const char *buf, size_t nbytes, int column_init, int tab,
+int flags)
+{
+ int column = column_init;
+ char const *p0 = buf;
+ char const *p;
+ char const *lim = buf + nbytes;
+
+ for (p = buf; p < lim; p++)
+switch (*p)
+ {
+case '\t':
+ column = add_column_width (column, p0, p - p0, flags);
+ column = add_column_width (column, NULL,
+ tab - ((column - 1) % tab), flags);
+ p0 = p + 1;
+ break;
+default:
+ break;
+ }
+ column = add_column_width (column, p0, p - p0, flags);
+ return column == INT_MAX ? INT_MAX : column - column_init;
+}
diff --git a/lib/mbswidth.h b/lib/mbswidth.h
index 0383b23..e967e49 100644
--- a/lib/mbswidth.h
+++ b/lib/mbswidth.h
@@ -54,6 +54,18 @@ extern int mbswidth (const char *string, int flags);
starting at BUF. */
extern int mbsnwidth (const char *buf, size_t nbytes, int flags);
+/* mbstnwidth (STRING, strlen (STRING), COLUMN_INIT, TAB, FLAGS) */
+extern int mbstwidth (const char *string, int column_init, int tab,
+ int flags);
Re: coreutils-8.4 very soon
Ian Beckwith wrote: > On Mon, Jan 11, 2010 at 10:25:53PM +0100, Jim Meyering wrote: >> Considering the coreutils-8.3 build failures, I'm going to release >> coreutils-8.4 soon, perhaps on Wednesday. A cursory review and >> preliminary testing suggests that it will be safe to use the latest >> from gnulib. Since you two have made relatively large changes recently, >> what do you think of using the latest in a bug-fix-only coreutils release? > > If you are feeling daring, you might want to try my just-released > stable snapshot. At Bruno's suggestion, I've been making periodic > stable snapshots of gnulib (well, this is only my second). I froze on > January 1st, and cherry-picked uncontroversial-looking fixes up until > January 9th. Thanks, but I've been testing unadulterated gnulib/master, up to date, to the minute ;-)
Re: coreutils-8.4 very soon
Bruno Haible wrote: >> Since you two have made relatively large changes recently, >> what do you think of using the latest in a bug-fix-only coreutils release? > > The changes between commit 7a29e0093f4a87478cdf7b7c87786272d6f37dfe and today > look reasonably safe. Most of new the libunistring tests won't affect > coreutils. Yet ;-) Thanks.
