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

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

On Fri, 25 Feb 2005 20:12:29 +0100
mips <mi...@ne...> wrote:

>  > 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.
> 
> Well i disagree with you on that.
> Broken code has nothing to do with dependencies. those bugs have to be 
> fixed upstream. Who would want to run something broken instead of 
> updating to a fixed release ?

Here is a current real world example. The snprintf function is defined
by the ISO C99 standard to have a very specific behaviour with regard to
its return value. However earlier implemtations which are not strictly
compliant still exist. If I have code that expects the C99 behaviour, 
I want to figure out if the C library on the host i am compiling on
is a C99 snprintf or a non-compliant snprintf.

Determining if the snprintf is C99 compliant can only be done with
an AC_TRY_RUN.

> So i expect to stand on my position concerning AC_TRY_RUN until i got a 
> good argument to not do so. 

I suggest that you use the snprintf problem as that argument.

An important feature of the C99 snprintf is (from the man page):

    The  functions  snprintf  and vsnprintf do not write more
    than size bytes (including the trailing '\0').   If  the  output  was
    truncated  due  to  this limit then the return value is the number of
    characters (not including the trailing '\0') which  would  have  been
    written to the final string if enough space had been available. Thus,
    a return value of size or more means that the output  was  truncated.

A common idiom for using snprintf is as follows:

    len = snprintf (NULL, 0, "x = %d, y = %f, z = %s\n", x, y, z) ;
    s = malloc (len + 1) ;
    snprintf (s, len, "x = %d, y = %f, z = %s\n", x, y, z) ;

There are many broken snprintf implementations where snprintf never
returns a value larger than the second parameter passed to it which 
means it cannot be used as in the example.

Yes, I agree that it should be fixed upstream, but upstream has
already fixed the problem; its called the next release of the
operating system. However, I have a client who doesn't want to or
can't do an OS upgrade, but wants to install my code which uses
snprintf in the above manner.

> Concerning the general "issue" you already got my answer 
> above.

Your answer for the general issue doesn't help with snprintf. There
are probably thousands of project whcih currently use autoconf to
detect this exact problem.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
Linux: the only OS that makes you feel guilty when you reboot
    -- Kenneth Crudup in comp.os.linux.misc