[PATCH] quotearg-file: new module

2012-10-20 Thread Oskar Liljeblad
Here's a new module that adds a function quotearg_file:
like quotearg_buffer but it writes the output to a FILE
instead. This prevents additional memory allocation if you
are quoting large data. And it provides a simpler API.

Regards,

Oskar Liljeblad (os...@osk.mine.nu)
diff -u1 ChangeLog.v0 ChangeLog
--- ChangeLog.v0	2012-10-21 00:10:14.043857761 +0200
+++ ChangeLog	2012-10-21 00:16:32.119146504 +0200
@@ -1 +1,15 @@
+2012-10-21  Oskar Liljeblad  os...@osk.mine.nu
+
+	quotearg-file: new module
+	* lib/quotearg-file.c:
+	New file: set QUOTEARG_FILE and include quotearg.c.
+	* lib/quotearg-file.h: New file.
+	* lib/quotearg.c:
+	When QUOTEARG_FILE is defined, generate only quotearg_file_restyled
+	and quotearg_file non-static functions. Otherwise everything is as
+	before, with the exception of default_quoting_options which is no
+	longer static to prevent a duplicate symbol in quotearg-file.o.
+	* modules/quotearg-file: New file.
+	* MODULES.html.sh (Misc): Add it.
+
 2012-10-16  Paul Eggert  egg...@cs.ucla.edu
diff -u -p /dev/null lib/quotearg-file.c
--- /dev/null   2012-08-16 17:10:46.538105184 +0200
+++ lib/quotearg-file.c 2012-10-20 23:40:18.696655540 +0200
@@ -0,0 +1,19 @@
+/* quotearg-file.c - quote arguments for output, writing result to file
+
+   Copyright (C) 2012 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see http://www.gnu.org/licenses/.  */
+
+#define QUOTEARG_FILE
+#include quotearg.c
diff -u /dev/null lib/quotearg-file.h
--- /dev/null	2012-08-16 17:10:46.538105184 +0200
+++ lib/quotearg-file.h	2012-10-20 23:56:34.364873603 +0200
@@ -0,0 +1,34 @@
+/* quotearg-file.h - prototypes for quotearg-file.c
+
+   Copyright (C) 2012 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see http://www.gnu.org/licenses/.  */
+
+#ifndef QUOTEARG_FILE_H_
+# define QUOTEARG_FILE_H_ 1
+
+#include quotearg.h
+
+/* Write to file handle FH a quoted version of
+   argument ARG (of size ARGSIZE), using O to control quoting.
+   If O is null, use the default.
+   Return the written size of the output, or EOF if there was an
+   error.
+   If ARGSIZE is SIZE_MAX, use the string length of the argument for
+   ARGSIZE.  */
+ssize_t
+quotearg_file (FILE *fh, char const *arg, size_t argsize,
+   struct quoting_options const *o);
+
+#endif /* !QUOTEARG_FILE_H_ */
diff -u -p quotearg.c.v0 quotearg.c
--- lib/quotearg.c.v0	2012-10-21 00:28:50.841568855 +0200
+++ lib/quotearg.c	2012-10-21 00:30:18.078326996 +0200
@@ -37,6 +37,9 @@
 #include errno.h
 #include limits.h
 #include stdbool.h
+#ifdef QUOTEARG_FILE
+#include stdio.h
+#endif
 #include stdlib.h
 #include string.h
 #include wchar.h
@@ -71,6 +74,7 @@ struct quoting_options
   char const *right_quote;
 };
 
+#ifndef QUOTEARG_FILE
 /* Names of quoting styles.  */
 char const *const quoting_style_args[] =
 {
@@ -97,10 +101,16 @@ enum quoting_style const quoting_style_v
   locale_quoting_style,
   clocale_quoting_style
 };
+#endif /* !defined QUOTEARG_FILE */
 
 /* The default quoting options.  */
-static struct quoting_options default_quoting_options;
+#ifndef QUOTEARG_FILE
+struct quoting_options default_quoting_options;
+#else
+extern struct quoting_options default_quoting_options;
+#endif
 
+#ifndef QUOTEARG_FILE
 /* Allocate a new set of quoting options, with contents initially identical
to O if O is not null, or to the default if O is null.
It is the caller's responsibility to free the result.  */
@@ -184,6 +194,7 @@ quoting_options_from_style (enum quoting
   o.style = style;
   return o;
 }
+#endif /* !defined QUOTEARG_FILE */
 
 /* MSGID approximates a quotation mark.  Return its translation if it
has one; otherwise, return either it or \, depending on S.
@@ -238,8 +249,13 @@ gettext_quote (char const *msgid, enum q
ARGSIZE, O), except it breaks O

Re: re-license 'byteswap' as LGPLv2+?

2008-03-05 Thread Oskar Liljeblad
On Wednesday, March 05, 2008 at 11:26, Simon Josefsson wrote:

Hi!

 Hi!  I wanted to use the 'byteswap' gnulib module in libntlm (licensed
 under LGPLv2), but it didn't work:
 
 gnulib-tool: *** incompatible license on module byteswap: LGPL
 
 The reason is that the 'byteswap' module says the license is 'LGPL'.
 
 Would it be possible to re-license module from 'LGPL' (I've forgotten
 which version that refers to) to LGPL version 2 or later,
 i.e. 'LGPLv2+', as the following patch?
[..patch removed..]

Yes, please do so. Please apply the patch.

Regards,

Oskar




Re: xvasprintf and HAVE_CONFIG_H

2006-10-16 Thread Oskar Liljeblad
On Monday, October 16, 2006 at 20:32, Eric Blake wrote:

Hi Eric!

 OK to apply this patch, to conform with the majority of gnulib that
 assumes config.h?

Of course!

Oskar




Re: iconv modules

2006-09-04 Thread Oskar Liljeblad
On Monday, September 04, 2006 at 14:53, Bruno Haible wrote:

Hi Bruno

[..] 
 All of these options are useful in some way or the other. Therefore I'd like
 to keep all the options, and distinguish them through a consistent
 nomenclature.
   - str vs. mem,
   - infix cd vs. none (similar to 'stat' and 'fstat' - the most natural 
 among
 the two has no prefix, the one taking a descriptor has a prefix),
   - x for checked memory allocation.
 
 So the proposal is:
 
   - Module 'striconv' (LGPL):
 
 exzern char *str_iconv (const char *string,
 const char *from_code, const char *to_code);
 extern char *str_cd_iconv (const char *string, iconv_t cd);
 extern int mem_cd_iconv (const char *start, size_t length, iconv_t cd,
  char **resultp, size_t *lengthp);
[..]

Sounds good to me - it would however be very useful if these functions would
null-terminate the generated strings properly as well. I assume str_iconv
and str_cd_iconv would add a single null-byte, but in some cases you'll need
two or even four null-bytes - e.g. when converting to UTF-16/UCS-2 and
UTF-32/UCS-4. One way would be to simply add four null bytes instead of one
all the time, or create another set of functions accepting a
'size_t n_null_bytes' argument.

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])





generic gcd

2006-04-28 Thread Oskar Liljeblad
I propose this patch to make gcd generic.
I needed an uintmax_t gcd for an application.
I hope the documentation in the module file is
useful - please improve it if possible.

Regards,

Oskar
diff -u -p -r1.4 gcd.c
--- lib/gcd.c   14 May 2005 06:03:58 -  1.4
+++ lib/gcd.c   28 Apr 2006 23:39:14 -
@@ -1,6 +1,7 @@
-/* Arithmetic.
-   Copyright (C) 2001-2002 Free Software Foundation, Inc.
+/* Greatest common divisor.
+   Copyright (C) 2001, 2002, 2006 Free Software Foundation, Inc.
Written by Bruno Haible [EMAIL PROTECTED], 2001.
+   Made generic by Oskar Liljeblad [EMAIL PROTECTED], 2006.
 
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -16,14 +17,16 @@
along with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
 
-/* Specification.  */
-#include gcd.h
-
 #include stdlib.h
 
+#ifndef gcd_t
+# define gcd_t unsigned long
+# define GCD gcd
+#endif
+
 /* Return the greatest common divisor of a  0 and b  0.  */
-unsigned long
-gcd (unsigned long a, unsigned long b)
+gcd_t
+GCD (gcd_t a, gcd_t b)
 {
   /* Why no division, as in Euclid's algorithm? Because in Euclid's algorithm
  the division result floor(a/b) or floor(b/a) is very often = 1 or = 2,
@@ -33,7 +36,7 @@ gcd (unsigned long a, unsigned long b)
  bit in a single instruction, and the algorithm uses fewer variables than
  Euclid's algorithm.  */
 
-  unsigned long c = a | b;
+  gcd_t c = a | b;
   c = c ^ (c - 1);
   /* c = largest power of 2 that divides a and b.  */
 
diff -u -p -r1.4 gcd
--- modules/gcd 22 Sep 2004 15:11:04 -  1.4
+++ modules/gcd 28 Apr 2006 23:39:15 -
@@ -1,5 +1,15 @@
 Description:
 Greatest common divisor.
+The default gcd function operates with `unsigned long' values.
+You can generate code for gcd functions that deal with other
+types of values by creating a .c source file containing code
+like this:
+  #define GCD gcdull
+  #define gcd_t unsigned long long
+  #include gcd.c
+Here `GCD' specifies the name of the function, and `gcd_t' the
+type of arguments and return value. Generated gcd functions
+will need to be declared manually.
 
 Files:
 lib/gcd.h


human dependency

2005-10-12 Thread Oskar Liljeblad
I think the human module depends on xstrtoumax, not xstrtol.

Regards,

Oskar

2005-10-12  Oskar Liljeblad  [EMAIL PROTECTED]

* modules/human: Depend on xstrtoumax, not xstrtol.

diff -u modules/human.v0 modules/human
--- modules/human.v02005-10-12 21:02:11.0 +0200
+++ modules/human   2005-10-12 21:02:47.0 +0200
@@ -16,7 +16,7 @@
 gettext-h
 argmatch
 error
-xstrtol
+xstrtoumax
 stdbool
 
 configure.ac:


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: stdint license

2005-10-06 Thread Oskar Liljeblad
On Wednesday, October 05, 2005 at 18:12, Bruno Haible wrote:
  I just noticed that the 'stdint' module was GPL.  Would it be possible
  to re-license it?
 
 Yes, done (assuming Oskar's agreement).

Of course, I don't think I coded anything in it anyway (I only came
up with the idea).

Regards,

Oskar


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


gnulib vs LIBOBJS,LIBINTL,LIBICONV...

2005-10-03 Thread Oskar Liljeblad
Normally you're supposed to add LIBOBJS, LIBICONV, LIBINTL, ALLOCA etc to
*_LIBADD/LDADD. But are these still necessary when using Gnulib (and the
appropriate modules such as iconv, gettext, alloca)?

Oskar


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: iconvme sync

2005-09-03 Thread Oskar Liljeblad
On Friday, September 02, 2005 at 19:13, James Youngman wrote:
 
  Hmm, another problem. I've signed a copyright assignment for Gnulib,
  but not for GNU libc. I guess that needs to be signed as well first?
 
 If your assignment was assign.future, the FSF now owns the code and
 can do what they like with it (for example, including it in glibc
 under a changed license if necessary).

Good. I think I signed assign.future (at least it is almost identical
to the template GNU assign.future documents found on the net).

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: iconvme sync

2005-09-02 Thread Oskar Liljeblad
On Friday, September 02, 2005 at 15:17, Simon Josefsson wrote:
 
  It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
  be synced from libc.  Are there libc bug reports or anything to
  associate with this, or are we just forked?
 
 Oops, I had forgot we were synced.  Oskar, do you want to file a glibc
 bug report for your iconvme changes, and include the patch?  Be sure
 to mention gnulib.  I can do it if it is troublesome for you, but not
 before Tuesday.

Hmm, another problem. I've signed a copyright assignment for Gnulib,
but not for GNU libc. I guess that needs to be signed as well first?

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: getdelim doesn't set errno on failure?

2005-08-24 Thread Oskar Liljeblad
On Wednesday, August 24, 2005 at 15:52, Bruno Haible wrote:
 
 I'm not in favour of a wrapper around malloc(), that would add overhead to
 a function called as frequently as malloc(), just to set 'errno'.
 
 ISO C 99 is not a substandard, and Windows malloc() is not poor just
 because it does not set errno.
 
 What value do you expect in errno after malloc() failed? ENOMEM is
 the most frequent and maybe also the only reasonable choice when malloc()
 fails. What's the purpose then of setting errno then?
 
 ISO C 99 is not a substandard, and Windows malloc() is not poor just
 because it does not set errno.

Gnulib already has a replacement malloc that handles malloc(0). Why not
extend that to set errno on failure as well?

Also, if we are to emulate a standard for broken systems, why not emulate
POSIX?

Regards,

Oskar


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


getdelim doesn't set errno on failure?

2005-08-23 Thread Oskar Liljeblad
I don't know if this is necessary or necessarily correct, but
it seems getdelim doesn't always set errno on failure (when it
returns -1).

From what I can tell, the test below (needed  cur_len) is to
test for overflow.

Oskar Liljeblad ([EMAIL PROTECTED])

Index: getdelim.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/getdelim.c,v
retrieving revision 1.1
diff -u -p -r1.1 getdelim.c
--- getdelim.c  2 Aug 2005 09:33:30 -   1.1
+++ getdelim.c  23 Aug 2005 14:38:56 -
@@ -28,6 +28,11 @@
 
 #include getdelim.h
 
+/* Some systems, like OSF/1 4.0 and Woe32, don't have EOVERFLOW.  */
+#ifndef EOVERFLOW
+# define EOVERFLOW E2BIG
+#endif
+
 #if !HAVE_FLOCKFILE
 # undef flockfile
 # define flockfile(x) ((void) 0)
@@ -86,6 +91,7 @@ getdelim (char **lineptr, size_t *n, int
 
  if (needed  cur_len)
{
+ errno = EOVERFLOW;
  result = -1;
  goto unlock_return;
}


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: getdelim doesn't set errno on failure?

2005-08-23 Thread Oskar Liljeblad
On Tuesday, August 23, 2005 at 17:59, Jim Meyering wrote:
 Oskar Liljeblad [EMAIL PROTECTED] wrote:
  I don't know if this is necessary or necessarily correct, but
  it seems getdelim doesn't always set errno on failure (when it
  returns -1).
 
  From what I can tell, the test below (needed  cur_len) is to
  test for overflow.
 
 Right.
 How about using ENOMEM instead?

Yes, that would be useful. It is hard as it is to handle errors from
getline. Also the documentation from GNU libc seems wrong:

 If an error occurs or end of file is reached without any bytes
 read, `getline' returns `-1'.

Here's what getdelim in Gnulib returns:

  -1, errno=EINVAL(an argument is NULL)
  -1, errno!=0(malloc failed, assuming malloc set errno)
  =0, errno undefined, feof  (getc returned EOF, reached end of file)
  =0, errno!=0, ferror   (getc returned EOF, read failed)
  -1, errno undefined (arithmetic overflow)
  -1, errno!=0(realloc failed, assuming realloc set errno)

So getline/getdelim only returns -1 on invalid arguments or an out of
memory condition, never on I/O errors or EOF!

Or did I miss something?

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: Opening a can of worms: a readline gnulib module?

2005-08-11 Thread Oskar Liljeblad
On Thursday, August 11, 2005 at 23:14, Simon Josefsson wrote:
 
  I don't know if the readline module covers this, but on recent
  Fedora/RedHat systems you'll need to link with ncurses or some
  other library providing certain termcap (or was it terminfo?)
  functions... You don't need to do this with Debian.
 
 This appears to be the case, I have access to one such system, so I
 can try M4 magic on it.  I have no idea how to solve this without a
 lot of code though (i.e., if AC_TRY_LINK fail, try the exact same
 AC_TRY_LINK again but with -ltermcap in LIBS too).  Relevant current
 code below.
 
 Thoughts?

I'll check the code soon, but why don't you use READLINE_LIBS instead
of LIBREADLINE etc? That's the convention most other automake macros
I've seen use. Oh well, I guess it's just my personal taste :)

Also check this:

http://ac-archive.sourceforge.net/Installed_Packages/vl_lib_readline.html

It also mentions libedit and libeditline (apparently those are other
GNU readline-like implementations).

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: tempfailure: adding TEMP_FAILURE_RETRY

2005-07-26 Thread Oskar Liljeblad
On Monday, July 25, 2005 at 16:37, Paul Eggert wrote:

  It backports the TEMP_FAILURE_RETRY macro from
  GNU Libc to Gnulib.
 
 The proposed implementation isn't portable; it assumes GCC syntax.
 And it should probably defer to the unistd.h implementation if available.

I did a grep for ({ and found other modules using the same syntax,
but when looking closer I realize that they provided non-GCC versions
for all macros as well. Doing TEMP_FAILURE_RETRY without macros won't
work...

So let's drop this idea...

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: warning: comparison is always false due to limited range of data type

2005-06-22 Thread Oskar Liljeblad
On Wednesday, June 22, 2005 at 11:50, Jim Meyering wrote:
  Isn't that a cure that is worse than the disease?  That patch will
  slow down the code on his platform, by causing the compiler to insert
  a run-time check where it now does the check at compile-time (and can
  therefore omit the call to xalloc_die ()).
 
  My own experience is that that particular warning is more trouble
  than it's worth.
 
 I agree.
 Sometimes I forget and still type `-W -Wall', forgetting that this
 type of warning comes from using gcc's -W option.
 These days, I rarely use -W (and never use it with -Werror),
 for precisely that reason.

I get that warning without both -W and -Wall, I think.
(gcc 3.3.6)

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: warning: comparison is always false due to limited range of data type

2005-06-22 Thread Oskar Liljeblad
On Wednesday, June 22, 2005 at 13:47, Jim Meyering wrote:
 
  I get that warning without both -W and -Wall, I think.
  (gcc 3.3.6)
 
 I've tried with the following versions of gcc on x86_64-unknown-linux-gnu:
   gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-6)
   gcc-3.4 (GCC) 3.4.5 20050605 (prerelease) (Debian 3.4.4-0)
   gcc-4.0 (GCC) 4.0.1 20050522 (prerelease) (Debian 4.0.0-9)
 
 and see that warning only with -W.

Strange! Is -W somehow turned on by default?

$ gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c quotearg.c
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of 
data type
$ gcc -DHAVE_CONFIG_H -I. -I. -I.. -c quotearg.c
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of 
data type
$ ../config.guess
x86_64-unknown-linux-gnu
$ gcc --version
gcc (GCC) 3.3.6 (Debian 1:3.3.6-6)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


warning: comparison is always false due to limited range of data type

2005-06-20 Thread Oskar Liljeblad
What's the proper way to fix these warnings?

quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data type

argp-help.c: In function `make_hol':
argp-help.c:430: warning: comparison is always true due to limited range of
data type
argp-help.c: In function `hol_append':
argp-help.c:831: warning: comparison is always true due to limited range of
data type

I get them on x86_64-unknown-linux-gnu.

Regards

Oskar


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


[bug-gnulib] comparison_fn_t

2005-05-27 Thread Oskar Liljeblad
GNU libc defines comparison_fn_t in stdlib.h if _GNU_SOURCE is defined.
The type is defined like this:

  typedef int (*comparison_fn_t) (const void *, const void *);

I tend to use this type a little everywhere, so I would like to make
a module for this definition. But what should the the header file be
called? comparison_fn.h? compfn.h? cmpfn.h?

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


[bug-gnulib] Re: config.charset of localcharset

2005-05-27 Thread Oskar Liljeblad
On Friday, May 27, 2005 at 13:25, Bruno Haible wrote:
  Shouldn't config.charset of the localcharset module be in build-aux
  rather than lib?
 
 Why? config.charset is not used by 'configure'.
 
 It's used by lib/Makefile, to create a file 'charset.alias' that is later
 installed. If you were to put config.charset under build-aux/, the Makefile
 rule would become more complicated because it would have to refer to
 the build-aux/ dir (which can be ../build-aux/ or ../../build-aux/ or worse).

I see. Its name, config.charset, was misleading me...

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


[bug-gnulib] Re: comparison_fn_t

2005-05-27 Thread Oskar Liljeblad
On Friday, May 27, 2005 at 13:26, Bruno Haible wrote:
  GNU libc defines comparison_fn_t in stdlib.h if _GNU_SOURCE is defined.
  The type is defined like this:
 
typedef int (*comparison_fn_t) (const void *, const void *);
 
  I tend to use this type a little everywhere, so I would like to make
  a module for this definition.
 
 You can do that in your own sources. But for gnulib, I would say it's
 bloat to define a module for nothing more than a typedef. Especially for
 a type that you can just as well spell out everywhere:
 
   extern void my_sort (void *, size_t, size_t,
int (*) (const void *, const void *));

Sure, but assume you're passing strcmp for the comparison function,
wouldn't you want to cast it to avoid the warning?

Regards,

Oskar Liljeblad ([EMAIL PROTECTED])


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib