Re: [AD] Problems with gcc 3.1

[salvador <salvador@xxxxxxxxxx>]

Peter Wang wrote:

> On 24 Oct 2001, salvador <salvador@xxxxxxxxxx> wrote:
> >
> > > (b) On the other hand, the conflicts are kind of rare.  So we should
> > > rename the f* functions to fix*, but provide aliases by default.  If
> > > the user really needs to use the libc/m fsqrt (etc) instead of
> > > Allegro's fsqrt (etc), he can switch off the aliases.  The aliases
> > > would be static inline functions, so even if you use Allegro's fsqrt
> > > in one module, you can still use the system's fsqrt in another.  If
> > > done right, there shouldn't be any warnings or anything.
> ...
> > If you go for (b) just add some mechanism to automagically disable the aliases.
> > Example: during configure mechanism detect if aliases collide, if that's the case
> > disable aliases
>
> This is what I had in mind.  Say math.h declares:
>
> float fsqrt(float);
>
> Then in the Allegro headers:
>
> fixed fixsqrt(fixed x);
>
> #ifndef ALLEGRO_NO_FIX_ALIASES
>    #ifdef ALLEGRO_MATH_FUNCTIONS_CONFLICT
>       #define fsqrt(x) (__get_out_of_the_way__fsqrt(x))
>       #include <math.h>
>       #undef fsqrt
>    #endif
>    static inline fixed fsqrt(fixed x) { return fixsqrt(x); }
> #endif
>
> What does everyone think of it?  Will it work?  It does mean the user
> will have to include allegro.h before math.h on systems that have
> conflicts, but that's not _hopelessly_ bad.

I don't know if this will solve gcc 3.1 case where the compiler itself says the
function is a *built-in* one.
I didn't check it in detail but the message implies that's a function the compiler
knows even when no header defines it.
It looks like gcc treats it like case, for, bool, etc.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set@xxxxxxxxxx set@xxxxxxxxxx
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013