headers
Oskar Liljeblad | 1 Jul 2004 10:04
Picon

ABS macro

Some time ago I wrote to this list about the lack of an ABS
(absolute value) macro. I'd like to ask again - is there any
chance we will see an abs module in the near future?

========================================

Description:
ABS macro.

Files:
lib/abs.h

Depends-on:

configure.ac:

Makefile.am:
lib_SOURCES += abs.h

Include:
"abs.h"

Maintainer:
<maintainer>

========================================

/* ABS macro.
   Copyright (C) 2004 <place copyright here>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Josefsson | 1 Jul 2004 16:58

Re: getopt trouble on uClibc systems

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

>> I have had troubles with AC_DEFINE re-defining core functions when
>> only parts of my project links with gnulib -- I typically don't want
>> to link gnulib in my libraries, but I want to make use of it in a
>> library command line interface.  I'll see if I can get it to work
>> without it.
>
> If you don't want gnulib in your libraries, but you do want it in your
> library, then I'm afraid you need to have a different config.h for
> your command-line interface than you do for your library -- at least
> if you use the part of gnulib that redefines symbols like 'malloc'.  I
> don't see an easy way around this problem.

I'm doing this in one project, but having two config.h complicates
things.  I haven't tried it, but merely renaming one of the config.h
to, e.g., cfg.h would probably be as complicated, since "config.h" is
hard coded all over the place.

> But you don't want to check whether these symbols are declared; you
> want to check whether they're defined.  (The distinction between
> definition and declaration is how this whole thread started....)
> That is, in:
>
>> #if !HAVE_DECL_OPTIND
>> int optind = 1;
>> #endif
>
> optind should be defined if it isn't supplied by the library; it
> shouldn't matter whether it's declared.  (You're not using the
(Continue reading)

Permalink | Reply | 14 comments |
headers
Simon Josefsson | 1 Jul 2004 17:38

config.h (was: Re: getopt trouble on uClibc systems)

Simon Josefsson <jas <at> extundo.com> writes:

>> If you don't want gnulib in your libraries, but you do want it in your
>> library, then I'm afraid you need to have a different config.h for
>> your command-line interface than you do for your library -- at least
>> if you use the part of gnulib that redefines symbols like 'malloc'.  I
>> don't see an easy way around this problem.
>
> I'm doing this in one project, but having two config.h complicates
> things.  I haven't tried it, but merely renaming one of the config.h
> to, e.g., cfg.h would probably be as complicated, since "config.h" is
> hard coded all over the place.

Incidentally, I noticed this in argz.c:

/* Provide our wierdo HAVE_CONFIG_H rvalue for other clients.  */
#if !defined(LTDL) && defined(HAVE_CONFIG_H)
#  define HAVE_CONFIG_H <config.h>
#endif

#if defined(HAVE_CONFIG_H)
#  include HAVE_CONFIG_H
#endif

This seem to suggest a solution to avoid hard coding the "config.h"
filename.  Perhaps '#include CONFIG_H' is more name space clean,
though.  Something like:

#ifdef HAVE_CONFIG_H
# ifndef CONFIG_H
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 1 Jul 2004 18:24

Re: getopt trouble on uClibc systems

Here's a first attempt.  The important part from getopt.m4 is:

  GETOPT_H=
  AC_CHECK_HEADERS([getopt.h], [], [GETOPT_H=getopt.h])

  AC_CHECK_FUNCS([optarg optind opterr optopt \
                  getopt getopt_long getopt_long_only], [],
    [GETOPT_H=getopt.h; AC_LIBOBJ([getopt]) AC_LIBOBJ([getopt1])
     AC_DEFINE([getopt], [rpl_getopt],
       [Define to rpl_getopt if the replacement function should be used])])

  AC_SUBST([GETOPT_H])

Comments (aka things I'm unsure about):

* The intention is to create a new getopt.h when it is needed.  If
  getopt.h doesn't exist on the system, it is created (of course).  If
  the system have getopt.h, but not getopt_long, be conservative and
  assume the system header file might be incorrect as well, and
  provide our own getopt.h.

* I'm abusing AC_CHECK_FUNCS for global variables.  This appears to
  work, but ignores the type of the variables.  If some system ever
  have those symbols, with other types, this part will have to be
  improved.

* 'getopt' is only redefined to 'rpl_getopt' when the system doesn't
  have all of the GNU getopt functions, like getopt_long.  So
  regardless of whether getopt is present or not on the system, as
  long as it doesn't have full GNU getopt, we use rpl_getopt.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Paul Eggert | 1 Jul 2004 19:38
Favicon

Re: ABS macro

Oskar Liljeblad <oskar <at> osk.mine.nu> writes:

> Some time ago I wrote to this list about the lack of an ABS
> (absolute value) macro.

Hmm, I looked at the archives, and I didn't see any followup to the
following somewhat-skeptical comment about ABS:

  ... why not use the absolute-value functions of stdlib.h, inttypes.h,
  math.h and tgmath.h?  Admittedly they're a bit of a mess (abs, labs,
  llabs, imaxabs, fabs, fabsf, fabsl, etc.), but they're the standard
  way to do it.  And they should do the right thing with NaNs and -0.0,
  whereas the macro won't.

  -- <http://lists.gnu.org/archive/html/bug-gnulib/2003-09/msg00270.html>
Permalink | Reply | 0 comments |
headers
Paul Eggert | 1 Jul 2004 19:47
Favicon

Re: config.h

Simon Josefsson <jas <at> extundo.com> writes:

> #ifdef HAVE_CONFIG_H
> # ifndef CONFIG_H
> #  define CONFIG_H <config.h>
> # endif
> #  include CONFIG_H
> #endif
>
> But I wonder if this is really portable CPP?

It's fairly portable in practice, but there are some gotchas.  The C
Standard says, "The method by which a sequence of preprocessing tokens
between a < and a > preprocessing token pair or a pair of " characters
is combined into a single header name preprocessing token is
implementation-defined."  It might be nice to find a better solution.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 1 Jul 2004 20:08
Favicon

Re: getopt trouble on uClibc systems

Simon Josefsson <jas <at> extundo.com> writes:

> * The variables are wrapped around HAVE_OPTFOO.

Come to think of it, shouldn't you replace the variables instead?  It
seems to me that the logic that applies to getopt (some nonstandard
and/or broken systems don't let you define your own getopt function)
will also apply (in similar form) to those variables.  For example, if
you use the system optind, many linkers will pull in the entire system
getopt object module, which is a waste and may cause a problem if they
define (say) getopt_long but not getopt_long_only.

E.g., perhaps you should append this to gl_GETOPT:

     AC_DEFINE([optarg], [rpl_optarg],
       [Define to rpl_optarg if the replacement variable should be used.])])

Then remove all uses of HAVE_OPTARG.  Similarly for optind, etc.

Another thing.  Once you make the above change, you can use a more
reliable way to check for the system getopt.  For example, you can
write a little test program that checks that
_GNU_GETOPT_INTERFACE_VERSION is 2 and refuses to compile otherwise.
If you want to get fancier, the test program could instead use all
the desired features (e.g., getopt_long) in such a way that there
will be a compilation or link error if the features don't work.

Then you don't need to use AC_CHECK_FUNCS or AC_CHECK_HEADERS; just
compile that program.  This is more reliable.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Simon Josefsson | 2 Jul 2004 09:46

Re: getopt trouble on uClibc systems

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

> Simon Josefsson <jas <at> extundo.com> writes:
>
>> * The variables are wrapped around HAVE_OPTFOO.
>
> Come to think of it, shouldn't you replace the variables instead?  It
> seems to me that the logic that applies to getopt (some nonstandard
> and/or broken systems don't let you define your own getopt function)
> will also apply (in similar form) to those variables.

I'm not convinced -- I believe there is a difference between getopt
and say opterr, so different logic apply.  For opterr, we can easily
test whether the system provided opterr is good enough.  If this
program compile, link, run and return 0:

#include <unistd.h>
#ifdef HAVE_GETOPT_H
#include <getopt.h>
#endif
extern int opterr;
int main (void) { return opterr == 1 ? 0 : 1; }

Then the system provided opterr is good enough, and there is no need
to replace it.

If the program doesn't work, for any reason, we should provide a
replacement, which may or may not have to be renamed depending on
whether the system provide a incompatible opterr.  Currently we don't
know of any systems that has incompatible opterr, so for now we simply
(Continue reading)

Permalink | Reply | 9 comments |
headers
Simon Josefsson | 2 Jul 2004 16:08

getndelim2.c:104: `ptrdiff_t' undeclared (first use in this function)

2004-07-02  Simon Josefsson  <jas <at> extundo.com>

	* getndelim2.c: Include stddef.h, for ptrdiff_t.  (FreeBSD 4.9
	failed without this.)

Index: getndelim2.c
===================================================================
RCS file: /cvsroot/gnulib/gnulib/lib/getndelim2.c,v
retrieving revision 1.7
diff -u -p -u -w -r1.7 getndelim2.c
--- getndelim2.c	16 May 2004 19:03:42 -0000	1.7
+++ getndelim2.c	2 Jul 2004 14:07:18 -0000
 <at>  <at>  -27,6 +27,7  <at>  <at> 
 #include "getndelim2.h"

 #include <stdlib.h>
+#include <stddef.h>

 #include "unlocked-io.h"
Permalink | Reply | 1 comment |
headers
Paul Eggert | 2 Jul 2004 19:19
Favicon

Re: getopt trouble on uClibc systems

Simon Josefsson <jas <at> extundo.com> writes:

> if it turns out that AC_CHECK_FUNCS is not sufficient to test
> whether opterr etc is working -- that is, instead getopt.m4 would
> have to compile the above long program -- then I believe TRT has
> become too ugly to support, and we should redefine the variables
> directly, just like for getopt.

Yes, I think that's what I was trying to say (perhaps not very
elegantly, sorry).

>> For example, if you use the system optind, many linkers will pull in
>> the entire system getopt object module, which is a waste and may
>> cause a problem if they define (say) getopt_long but not
>> getopt_long_only.
>
> If this situation exists, using my logic, the solution to that problem
> would be to redefine getopt_long to rpl_getopt_long -- similar to
> getopt.

OK.  Let's replace getopt_long and getopt_long_only as well.  That's
more consistent anyway.

>> If you want to get fancier, the test program could instead use all
>> the desired features (e.g., getopt_long) in such a way that there
>> will be a compilation or link error if the features don't work.
>
> And then replace all symbols?

Yes, that's the idea.  It's a straightforward approach.
(Continue reading)

Permalink | Reply | 8 comments |

Gmane