Re: [Pmk-users] Can PMK do things like AC_TRY_RUN?

[Erik de C. L. <eri...@me...>]

On Tue, 01 Feb 2005 17:03:01 +0100
Damien Couderc <mip...@us...> wrote:

> Hi Erik,
> i've finaly found some time to check your second problem.
> 
> I knew that one day i'll get this question :)
> One of the reasons that made me starting PMK was the problem that
> occured some time ago with trojans hidden in configure scripts. 

Thats a worthy goal and I applaud you for trying to meet it.

> The
> solution in my mind was to replace scripts by data files. So the threat
> is located only in pmk code instead of every configure scripts.
> 
> Until now we always found an alternative for AC_TRY_RUN and i hope we'll
> always succeed in that :)

If you are attempting to replace autoconf, then I think you will fail
if you cannot provide a facility like AC_TRY_RUN. YOu can replace 
certain specific uses of it, but not the general case.

In the general case, a developer finds some bug or feature that can only
be detected at run time and would like to detect the presense/absence
of that feature at configure time.

The only way to do this in the general case is to provide a feature
like AC_TRY_RUN, possibly using something like a chroot jail.

> I've looked quickly at your m4 macro so i get the main idea of what
> you're checking. Now i'm wondering if this is a bug or a feature, could
> you provide me an URL that explain a bit more this phenomenon ?

There is no URL. As far as I am aware, I am the only person who uses
this "feature".

Both of my libraries contain code for doing conversions of floats/doubles
in the range [-1.0, 1.0] to shorts and ints. On top of that, if the source
float/double would overflow the destination short/int, them the float/
double should be clipped to the maximum allowable value of the destination
format before the conversion. The naive implementation of a float to
short conversion with clipping is :

     inline short f2s (float src)
     {    src *= 32767.0 ;
          if (src > 32767.0)
             return 32767 ;
          if (src < -32768.0)
             return -32768 ;
          return (short) src ;
     }
 
When doing this on large arrays of numbers, the two if statements slow
down execution significantly. However on PowerPC, I know that I can 
replace the above code with:

     inline short f2s (float src)
     {    int dest = (int) (src * MAX_INT) ;
          return (src >> 16) ;
     }

By removing the two if statements, the above code runs significantly
faster and produces the same result. The "trick" is that when a 
float is converted to an int on PowerPC, the CPU automatically, in
silicon, does this :

     if (src > MAX_INT)
         dest = MAX_INT ;
     else if (src < MIN_INT)
         dest = MIN_INT ;
     else
         (int) src ;

which I consider the "correct" thing to do. X86 CPUs, only do the 
"correct" thing on negative floats which means I still need an if
statement to check for positive floats that would overflow.
Other CPUs? I don't know; so I use AC_TRY_RUN.

So, I've explained what my M4 macro does, but I urge you not to address
this specific issue but the general issue that AC_TRY_RUN solves.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"Always code as if the person who ends up maintaining your
code will be a violent psychopath who knows where you live."
-- Martin Golding