.
(assume_nonnull): New macro.
diff --git a/lib/xreadlink.h b/lib/xreadlink.h
index ef749babe..fb7cea710 100644
--- a/lib/xreadlink.h
+++ b/lib/xreadlink.h
@@ -18,8 +18,12 @@
/* Written by Jim Meyering */
-extern char *xreadlink (char const *filename);
+#include
+
+extern char *xreadlink (char const
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> as far as I can see, no one even uses xreadlink any more, so it's not urgent.
>
> The 'relocatable' facility uses xreadlink.
>
>> However, your point about the "a" vs. "m
Hello Jim,
> as far as I can see, no one even uses xreadlink any more, so it's not urgent.
The 'relocatable' facility uses xreadlink.
> However, your point about the "a" vs. "m" prefix is valid,
> and I've just renamed mreadlink-with-size.
Than
n gnulib, nor in coreutils. Remember
Ha! Good point. But as far as I can see, no one even uses xreadlink
any more, so it's not urgent.
However, your point about the "a" vs. "m" prefix is valid,
and I've just renamed mreadlink-with-size.
en xreadlink_with_size and xreadlink was that
in one case a (likely good) estimate for the size is already known and in
the other case there is no such estimate.
Also, about the naming convention: In the *printf family of functions,
the prefix 'a' is used to denote a function that alloc
I did most of this weeks ago and just noticed I never checked it in.
Ok with you, Bruno?
Rewrite xreadlink as a trivial mreadlink wrapper.
* lib/xreadlink.c (xreadlink): Rewrite as a simple mreadlink wrapper.
* modules/xreadlink: Adjust dependencies.
Index: lib
* lib/xreadlink.c: Include unconditionally.
* modules/xreadlink (Depends-on): Add unistd.
* modules/xreadlink-with-size (Depends-on): Likewise.
*** lib/xreadlink.c 1 Mar 2007 00:07:34 - 1.25
--- lib/xreadlink.c 3 Mar 2007 19:15:44 -
***
*** 31,39 ***
Bruno Haible <[EMAIL PROTECTED]> wrote:
> And here's the accompanying coreutils patch. The call in src/readlink.c
> is actually better served with the 1-argument xreadlink(), since memcopying
> a small string is typically faster than a memory allocation of 1 KB.
>
>
And here's the accompanying coreutils patch. The call in src/readlink.c
is actually better served with the 1-argument xreadlink(), since memcopying
a small string is typically faster than a memory allocation of 1 KB.
2007-02-28 Bruno Haible <[EMAIL PROTECTED]>
* boo
; or, shortest of all ("2", for two parameters),
> xreadlink2
>
> So far, I prefer xreadlink2.
OK. In private mail you said that 'xreadlink_with_size' was also acceptable
to you. I applied the following patch.
NOTE for gnulib users:
- The module 'xreadlink&
Bruno Haible <[EMAIL PROTECTED]> wrote:
> What can we do in gnulib?
>
> (a) Have 2 xreadlink like functions. Since the one without prior stat is more
> natural, I would propose to rename the coreutils one, with the 'size'
> argument, to 'xreadlink_after
Hi Jim,
Ben Pfaff noticed that there two versions of xreadlink in gnulib and gettext
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gnulib/lib/xreadlink.c?content-type=text%2Fplain&rev=1.23&root=gnulib
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/xre
Ben Pfaff <[EMAIL PROTECTED]> writes:
> --- modules/xreadlink 12 Aug 2005 12:21:44 - 1.7
> +++ modules/xreadlink 2 Oct 2005 23:37:04 -
> @@ -14,9 +14,6 @@ ssize_t
> configure.ac:
> gl_XREADLINK
>
> -Makefile.am:
> -lib_SOURCES += xreadlink.h xreadli
The xreadlink module is provoking the following error in Automake
1.9.
gl/Makefile.am:17: automatically discovered file `xreadlink.h' should not be
explicitly mentioned
gl/Makefile.am:17: automatically discovered file `xreadlink.c' should not be
explicitly mentioned
Applying this p
14 matches
Mail list logo
