[Top][All Lists]

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

Re: supported version of glibc, workarround to gnulib and math constant

From: Bastien ROUCARIES
Subject: Re: supported version of glibc, workarround to gnulib and math constant module
Date: Fri, 2 Jul 2010 11:11:57 +0200

On Fri, Jul 2, 2010 at 2:01 AM, Bruno Haible <address@hidden> wrote:
> Hi Bastien,
>> I am trying to port harminv to gnulib.
>> However this package has the following code in order to work arround a
>> weird bug in glibc 2.2.5. Do you support this lib ?
>> If you use the complex clog function in a pure c program library than
>> link from another (C++) program, the program seems to crash from this
>> c++ program. It seems related to
>> a conflict between class clog of c++ and function clog. Upstream of
>> harminv use the following workarround:
>> #undef clog
>> #define clog my_clog
>> static cmplx my_clog(cmplx z)
>> {
>>      return (log(cabs(z)) + I * carg(z));
>> }
>> Does this kind of workarround is suitable for gnulib ?
> I don't exactly understand what the problem/bug is. Ulrich Drepper claimed
> to have solved it already for glibc 2.1 ([1] page 35).

For sure it is surelly on older libc++, and surelly a transient
conflict. Not worth the effort.

> So far gnulib has no support for these complex functions, because they take
> arguments of type 'complex double', and not all compilers support this type.
> For those that don't, there is no substitute.
> But if you want to start extending gnulib in the direction of complex 
> functions
> - assuming the type 'complex double', but fixing all other kinds of problems -
> you're welcome!

If you have some documented problem, i could give a try.

>> Another question do you accept a package a math constant like for
>> instance M_PI and other constant? It will be really useful for math
>> and physics program to get a resonnable loist of math constant by
>> default.
> I agree, it would be useful. We have a module 'math', which provides a
> substitute <math.h>, but so far, we have dealt with NAN and HUGE_VAL only.
> If you know portability problems for M_PI and other constants, please tell
> us or provide patches to
>  doc/posix-headers/math.texi
>  lib/math.in.h
>  m4/math_h.m4

M_PI is defined under linux if _USE_BSD, __USE_XOPEN, __USE_GNU
A lot of portable scientific code use stuff like :
#ifndef M_E
#define M_E        2.71828182845904523536028747135      /* e */

#ifndef M_LOG2E
#define M_LOG2E    1.44269504088896340735992468100      /* log_2 (e) */

#ifndef M_LOG10E
#define M_LOG10E   0.43429448190325182765112891892      /* log_10 (e) */

Under mingw if only #ifndef __STRICT_ANSI__

And some constant are missing like M_TWOPI

> Bruno
> [1] http://people.redhat.com/drepper/tut1.ps

reply via email to

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